Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Replies 4 replies
  • Subscribers 7 subscribers
  • Views 1721 views
  • Users 0 members are here
Options
Suggested

[NC-52638] SFOS 18.0.0 EAP1-Refresh1 is not able to route local services trough IPSec tunnels

Bert Janssen1

Hi, 

It seems that i have several issues with routing local services that run on the XG trough IPSec tunnels.

I have the following scenario's:

WAF connects for Exchange via IPSec to a datacenter server via an IPSec tunnel
SMTP routes specific domains to a static host to a datacenter via an IPSec tunnel
Both Services do not seem to be able to connect trough the IPSec tunnel anymore after upgrading to the Beta.

ping and telnet to the server form the advanced console seems to work fine but somehow the local services like SMTP proxy and WAF are not able to connect.

I have tried disabeling MASQ/NAT rules or creating an specific one to skip MASQ but this did not seem to fix it.

Any suggestions?

Parents
  • 0

    Can confirm I'm seeing the same issues, rolled back to previous v18 release and was able to connect back to my off Premises Azure DC.  

    Spent a few days trying multiple different troubleshooting steps and could not resolve.  

    What changed between releases that broke IPsec routing. Can ping back in from Azure no problems.

  • 0 in reply to W777

    Not entirely sure if this is related, but even with prior versions, by default it was not possible to monitor an XG via SNMP through a VPN tunnel. You had to create a custom route on the XG for system generated traffic. Depending on how your routing is configured, it may not apply to system traffic, especially if you're using all the automatically created (migrated) firewall rules from an upgrade from v17. Those don't apply to system traffic. You'll have to recreate those. You can see the check box in the rules saying "Do not apply this migrated rule to system-destined traffic." This can't be removed unless you create a new rule.

  • 0 in reply to Bjoern Freiherr

    Thankyou Bjoern for taking time out to input, definitely helping me understand how the different layers are working in v18.

    For the moment it just seems very inconsistent so have moved to using OpenVPN SSL (which is actually very good!) for Android client VPN and rolled back to the initial release.

    Rolling back to initial v18.000 solved the Azure routing over IPSec without any changes to the rules (both NAT and FW)

    I also confirmed that other Android phones are also having the same issues with routing to internal hosts over IPSec client VPN (where iOS is working fine) as I mentioned here..  

    I will skip Refresh-1 for now, but looking forward to the next release to see if it fixed any of this weirdness :)

    Thanks again

Reply
  • 0 in reply to Bjoern Freiherr

    Thankyou Bjoern for taking time out to input, definitely helping me understand how the different layers are working in v18.

    For the moment it just seems very inconsistent so have moved to using OpenVPN SSL (which is actually very good!) for Android client VPN and rolled back to the initial release.

    Rolling back to initial v18.000 solved the Azure routing over IPSec without any changes to the rules (both NAT and FW)

    I also confirmed that other Android phones are also having the same issues with routing to internal hosts over IPSec client VPN (where iOS is working fine) as I mentioned here..  

    I will skip Refresh-1 for now, but looking forward to the next release to see if it fixed any of this weirdness :)

    Thanks again

Children
No Data
Unfiltered HTML