topic Re: IPSec Tunnel Failing to establish in General Topics

IPSec Tunnel Failing to establish

C2CDan — Mon, 07 Oct 2019 16:46:24 GMT

Hi all,

I'm having issues establishing an IPSec tunnel between two R80.30 open servers. There's nothing particularly special setup, just two sites A & B. Site A has the SMS and one firewall and B has just a firewall. Communication with the Site B firewall is fine (although we’ve had to add an explicit allow rule for any traffic originating from Site A to manage the Site B firewall, as if the implied rule isn’t working??) until we try to push a VPN community to it, at which point we lose SIC to the Site B firewall and see the following output on the B firewall with fw ctl zdebug drop

@;23607731;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=6 xx.xx.xx.xx:27047 -> xx.xx.xx.xx:18191 dropped by vpn_drop_and_log Reason: Clear text packet should be encrypted;

A SIC reset goes through fine and all other management of the firewall in B seems ok, albeit requiring an explicit allow rule.

We've yet to see the tunnel establish but expect if we resolve the above we'll get resolution on the tunnel establishment

Grateful for any pointers!

Cheers,
Dan

Re: IPSec Tunnel Failing to establish

Maarten_Sjouw — Mon, 07 Oct 2019 21:10:13 GMT

Normally all management traffic is passed outside the tunnel, this way you cannot lock yourself out. It looks like either side thinks the traffic still should be encrypted, which it should not. You can try to add the management ports explicitly in the exclusion list for the specific VPN community.
Also make sure you have a proper NAT setup for the SMS (make sure to use a separate NAT-IP for the SMS)

Re: IPSec Tunnel Failing to establish

FedericoMeiners — Tue, 08 Oct 2019 00:40:55 GMT

Additionally to what Maarten stated: Make sure that encryption domains don't include GWs public IPs, also make sure to check this option in your management NAT settings

Re: IPSec Tunnel Failing to establish

C2CDan — Tue, 08 Oct 2019 22:14:39 GMT

Hi Maarten, Frederico,

Thanks for the pointers re management traffic, we'd missed having a dedicated NAT and since breaking the SMS out to it's own WAN IP we've stopped the issue of losing management control of the remote gateway, thank you!

Sadly, we're still struggling to get the tunnel going, Maarten, I suspect you may be right with regards ensuring the encryption domains don't include the public IPs of the gateways. That being said, everything on the VPN setup is very 'vanilla'. Where/how can we double check this?

Many thanks,
Dan

Re: IPSec Tunnel Failing to establish

C2CDan — Tue, 08 Oct 2019 23:37:40 GMT

Hi all,

FYI, in the course of troubleshooting this I've come across the following output:

I'm assuming, the 'My TS' information should be the local subnet being presented to the opposite Gateway, in the same way the Peer TS is a local subnet? In our case, My TS is showing the WAN address of this gateway?

Also, seeing 'No outbound SA', would this indicate the local Gw we're ssh'd into isn't attempting to initiate connections at all?

Cheers,
Dan

PS Peer in this instance, I assume is not the peer ID but rather the text description from the SMS?

Re: IPSec Tunnel Failing to establish

FedericoMeiners — Wed, 09 Oct 2019 02:35:32 GMT

Dan,

You are managing both gateways with the same management right?

Please check if you can manually set the encryption domain for both gateways so you can share specific subnets, by default its configured to share all topology.

VPN Domain - Manually defined. Don't look at the other red squares 🙂

Finally I highly suggest you to use IKEView to further debug your VPN, this will give us a closer hint. This will tell us which Phase is failing and mostly why. This tool is safe to use on production.

Re: IPSec Tunnel Failing to establish

C2CDan — Wed, 09 Oct 2019 10:28:25 GMT

Hi Federico,

Thanks for the hint re IKEView, looks to be a really good tool and has certainly illuminated the path!

From IKEView we can see the following:

Site A GW - Local host ==> Remote peer(Public IP)

However from the Site B GW IKE log we're seeing: Local host ==> Remote peer(192.168.xx.xx) where 192.168.xx.xx is the private IP of the Site A GW

It looks to me like the main/management IP of the Site A GW is being presented as the peering IP, however, we've explicitly set this to be the WAN IP of Site A GW as per the below:

We did wonder if we should remove the Site A GW from the SMS and re-add with it's main WAN IP? But equally, would expect the above to take care of the peering element?

Many thanks for the help so far!

Cheers,
Dan

Re: IPSec Tunnel Failing to establish

Maarten_Sjouw — Wed, 09 Oct 2019 11:01:50 GMT

You also need to make sure the Outgoing part is configured to properly use the External IP, you do this in the Source IP address settings set to manual and selected IP from topology.

Re: IPSec Tunnel Failing to establish

FedericoMeiners — Wed, 09 Oct 2019 14:02:36 GMT

Re: IPSec Tunnel Failing to establish

C2CDan — Wed, 09 Oct 2019 14:26:02 GMT

Hi both,

Thanks for the pointers, we'd come across the source IP setting during our troubleshooting and already set it as the external IP:

Afraid we're still seeing the same thing in IKEview that the peer target for site B is the private rather than public IP of the site A gateway.

Do we need to look at removing the site A Gw and adding it back in with it's WAN IP to the SMS. Feels like a bug somewhere?

Cheers,
Dan

Re: IPSec Tunnel Failing to establish

Maarten_Sjouw — Wed, 09 Oct 2019 14:46:48 GMT

removing is not needed, you can change the IP on the object and do not need to replace it to do so.
Have you pushed policy to both gateways, after changing this setting?

Re: IPSec Tunnel Failing to establish

C2CDan — Wed, 09 Oct 2019 15:08:07 GMT

Hi Maarten,

Thanks for the response, yes we've installed the policy since making the change

Re changing the IP, is it normal to chance the IP to the WAN IP or should it not really matter and should be picking up the route setting?

Thanks,
Dan

Re: IPSec Tunnel Failing to establish

Maarten_Sjouw — Wed, 09 Oct 2019 15:27:53 GMT

It really should not matter at all. As you are managing the gateway from the LAN side it is normal to use that interface as the object IP.
It would not hurt to change tge setting, publish, change it back and publish and push the policy again.