FixMaker's questions

I am trying to make an IPsec connection to a FortiGate router using OpenSwan. The FortiGate sits on two distinct subnets and I need to access both of them. In the FortiGate I have defined one Phase 1 connection and one Phase 2 connection. This allows me to successfully make a connection to one of the subnets.

I need to be able to access both subnets at the same time. The received wisdom seems to be to create two separate connections (one per subnet) in OpenSwan and when making an additional connection it will automatically attempt to reuse an existing phase 1 tunnel (when creating a new phase 2 tunnel for the additional connection).

When I bring up both connections, according to the logs it seems OpenSwan is stuck in a continuous loop of attempting renegotiate each connection in turn (I can only ping one subnet at any one time). I'm guessing this is because the FortiGate is dropping the existing connection when a new one is attempted.

I have the following questions:

• How should I configure the FortiGate to allow two concurrent connections from the same IPsec initiator (one connection per subnet)? Is this even possible? (The documentation seems to be a bit vague on this.)

• Do I need to specifically associate a phase 2 connection in the FortiGate to a specific subnet, and if so, how do I go about doing this?

• Are there any issues/gotchas when making multiple IPsec VPN connections between the same endpoints?

I currently have a server that nightly backs up its data to a NETGEAR ReadyNAS device using Rsync. This has been working fine for the past few months. However recently, I started to get the following error:

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Connection reset by peer (104)
inflate (token) returned -5
rsync error: error in rsync protocol data stream (code 12) at token.c(604) [receiver=3.0.6]
rsync: connection unexpectedly closed (229743 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7]

I've managed to track it down to one particular file that is causing the problem (by using Rsync to copy just that file). The file itself is quite large - about 975Mb. However, there are also other files in the same directory, some as large as 3Gb, and these backup fine.

I'm using the following Rsync command:

 rsync -avz --password-file=/root/rsync.secret <sourcedir> username@readynas::backup

Rsyncing to an Ubuntu Linux host seems to work, so it doesn't look like there's a problem with the rsync client on the server.

I've Googled around but found nothing. A lot of people seem to be saying that adjusting the timeout at the Rsync server end solved similar problems, but if this were my problem I can't understand why it works with the larger files.

Does anyone have any suggestions how to solve this?

We currently have all our email stored on a Dovecot IMAP server in our internal network. Client machines on the network are able to connect and access their email.

Now we want to allow certain users to be able to connect in and view their email from the outside using IMAP. We currently have a firewall/router with a dedicated (unused) DMZ port. The way I see it we have two options:

1. Set up port forwarding on the router to forward any IMAP requests on ports 585 or 993 to the server; the server can then validate the user.
2. Attach a reverse proxy IMAP server to the DMZ of the router; this in turn can forward the IMAP requests to the server on the internal network (with the possible option of validating the user-name before doing so).

Does anyone have any suggestions/comments on the merits of either approach?

I'm find it difficult to think of any read advantages to having an extra reverse-proxy in the DMZ of a three-legged firewall, since it's pretty much just going to effectively be doing port forwarding anyway. ...Or am I missing something?