Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
C2CDan
Participant

IPSec Tunnel Failing to establish

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

 

0 Kudos
12 Replies
Maarten_Sjouw
Champion
Champion

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)
Regards, Maarten
FedericoMeiners
Advisor

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

2019-10-07 21_39_35-Window.png

____________
https://www.linkedin.com/in/federicomeiners/
C2CDan
Participant

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

0 Kudos
C2CDan
Participant

Hi all,

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

vpntutlist.JPG

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?

FedericoMeiners
Advisor

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 🙂

enc dom.png

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.

 

____________
https://www.linkedin.com/in/federicomeiners/
0 Kudos
C2CDan
Participant

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:

selectedAddress.PNG

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

0 Kudos
Maarten_Sjouw
Champion
Champion

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.
Regards, Maarten
0 Kudos
FedericoMeiners
Advisor

24_1.png

____________
https://www.linkedin.com/in/federicomeiners/
0 Kudos
C2CDan
Participant

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:

sourceAddress.PNG

 

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

0 Kudos
Maarten_Sjouw
Champion
Champion

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?
Regards, Maarten
0 Kudos
C2CDan
Participant

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

0 Kudos
Maarten_Sjouw
Champion
Champion

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.
Regards, Maarten
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events