Some background... we have colocated some servers that were previously located in our office on 2 different networks. I kept all of those colo'd servers with their same IP addresses (172.16.1.0/24 & 172.16.2.0/24 networks).

Back at the office, I changed the former DMZ interface to a dummy IP, as no more servers hang off of that leg. I changed the internal interface to another private address space (10.10.10.0/24) and some ancillary cleanup around that change [DHCP range, DNS server, etc.].

Then I enable the IPSec trial and work with our colo provider to establish the IPSec tunnel between our untangle and the firewall that they support (Fortigate 80C). After some trial and error, we finally get the tunnel itself up. BUT we're having trouble passing actual traffic in one of the directions.

What's really curious to me is that when I'm sniffing the external interface of the Untangle server and initiate a tcp connection that should route across the IPSec tunnel, I do not see any ESP packets floating across. However, if I'm on one of the 172.16.1.0/24 servers at the colo site, I AM able to connect into our internal office network (10.10.10.0/24) and I see the ESP packets in my tcpdump.

I'm suspecting that since I'm not seeing any ESP packets when starting the connection from "behind" the untangle, that the untangle may be to blame. If I read the docs right, traffic destined for the IPSec tunnel should always go to the tunnel and bypass everything controlled by the UVM (firewall, port forwards, etc.). But it seems that may not be happening.

We have live support but that doesn't help on the weekends.

Here are some of the relevant logs showing the tunnel as being up and by all accounts should be passing the traffic in both directions.

(a.b.c.d is our external IP, w.x.y.z is the external IP of the firewall at our colo provider)

IPSec state:
src a.b.c.d dst w.x.y.z
proto esp spi 0x09d71fc7 reqid 16385 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) <censored>
enc cbc(des3_ede) <censored>
src w.x.y.z dst a.b.c.d
proto esp spi 0x1817d0db reqid 16385 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) <censored>
enc cbc(des3_ede) <censored>

(172.16.1.0/24 is the network now behind the colo firewall and previously was on internal office network; 10.10.10.0/24 is the new internal office network. This isn't a paste error, the src 172.16.1.0/24 appears twice - could this be related to my problem? Seems it wouldn't be as my problem is leaving the office network heading to the colo network.)

IPSec policy:
src 172.16.1.0/24 dst 10.10.10.0/24
dir in priority 2344
tmpl src w.x.y.z dst a.b.c.d
proto esp reqid 16385 mode tunnel
src 172.16.1.0/24 dst 10.10.10.0/24
dir fwd priority 2344
tmpl src w.x.y.z dst a.b.c.d
proto esp reqid 16385 mode tunnel
src 10.10.10.0/24 dst 172.16.1.0/24
dir out priority 2344
tmpl src a.b.c.d dst w.x.y.z
proto esp reqid 16385 mode tunnel


Would appreciate any pointers... and I'll be calling support on Monday if there's no resolution.