Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Migrate single IPSec tunnel to different public interface?

Hello,

At our headquarters, we currently have a 2MBit SDSL-line over which our branch sites are connected via IPsec site-to-site tunnels.

Recently, we got a 5 MBit "Business Connect" line from Deutsche Telekom (I have no idea what that line uses under the hood, they installed some Cisco router, to which the Astaro connects via Ethernet, using a static public IP address), and now we want to migrate our IPsec tunnels to the new line, then turn the SDSL line off, once everything works.

The first branch office we migrated has a RED, so that worked very easily and painlessly. Then we moved on to the second office, which uses another Astaro.

We changed to definition of the IPsec tunnel on the Astaro at the branch site, so that it would connect to the new IP address, then we changed the tunnel on the Astaro at our headquarters, so it would accept the IPsec tunnel from that branch site at the new interface.

The IPsec part seemed to work - after a moment, both Astaros reported that the IPsec tunnel was up again. Nagios reported it could once more ping the devices in the branch office (the Astaro, plus two printers and a NAS). 
But then we connected to one of the PCs at the branch site using TeamViewer and tried to access one of the file shares at our headquarters, without success. We opened a command line and tried to ping one of our servers (located, again, at our headquarters) by name - the ping command took a long time, then it emitted a message that it could not resolve the host name. We tried to ping that server by its IP address, which worked fine.
We tried to access a file share on a PC at the branch site, again without success.

I checked the packetfilter log on the Astaro at our headquarters. Obviously, the IPsec tunnel itself worked fine, but anything except ICMP seemed to get blocked by the firewall.
And indeed, the firewall reported lots of dropped packets. I checked the output of "iptables -L", and the rule causing those packet to get dropped was the default rule from the FORWARD chain: 
LOGDROP    all  --  anywhere             anywhere             LOGMARK match 60002

So it looks like no rule matches those packets between that branch site and our headquarters, causing them to hit the default rule, which drops them and tells the log about it.

I tried to deactivate, then reactivate the "Automatic packet filter rule" checkbox in the IPsec settings, but the situation remained the same.
I tried manually adding two rules to the firewall that allow all traffic to pass between the branch site and our headquarters. But it did not change the situation.

Can somebody tell me if I am missing some minor detail, or is my whole approach misguided? Should I recreate the entire IPsec tunnel? What confuses me is that the IPsec tunnel itself appears to work just fine, when I switch it to the new interface, while the packet filter appears to block non-ICMP traffice from the branch site network via the new interface.

I would really appreciate any sort of advice or pointers to where my mistake might lie.
Thank you very much!


This thread was automatically locked due to age.
  • Just moved some VPNs from one line to another a month or so ago. Worked without any problems.

    My first idea:
    Can you please check all definitions used in your VPN configuration? Maybe it's bound to the old WAN interface instead of "Any"? Definitions used in firewall rules for VPN traffic anyway have to be "bound to any" to work fine.
  • Can you please check all definitions used in your VPN configuration? Maybe it's bound to the old WAN interface instead of "Any"? Definitions used in firewall rules for VPN traffic anyway have to be "bound to any" to work fine.


    Thank you very, very much!!! [:D]
    That did the trick - the network definition for the remote office was bound to the "old" WAN interface, we changed that to the new interface, it works now.
    Again, thank you very much for your quick reply!
  • Hi, krylon, and welcome to the User BB!

    You might be interested in Rulz, especially #3.  The UTM doesn't need binding in this instance, and probably not any you ever will see.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi, krylon, and welcome to the User BB!

    You might be interested in Rulz, especially #3.
    Cheers - Bob


    Thank you very much for the advice! As we are migrating our other branch sites to the new WAN line, I will check and adjust the settings for all remote networks and hosts.