ASA5525-X Site to Site VPN

[nick.armitage]

Hi,

I'm currently trying to establish a site-to-site VPN between a pair of ASA5525-X with FirePower devices, I've tried both the wizard and the CLI to establish the VPN but I see no connections, someone else has reviewed the config and it looks okay. I have a thought and wonder if someone could confirm or deny this please?

The devices have one physical ethernet connection to the outside world (gi0/0 (outside)) which is split into 3 logical interfaces (gi0/0.1 (outside-man), gi0/0.2 (outside-user) and gi0/0.3 (outside-data)). I am trying to establish the VPN through the gi0/0.1 interface (on both sides) but the VPN does not even appear to attempt to establish. I can confirm there is connectivity between the devices (ping between each others gi0/0.1 interface responds and I can netcat a UDP message on port 500 from servers internal to each firewall to the server on the other side via the gi0/0.1 interface. Should I be able to establish the VPN between the logical interfaces or should it be via the physical interface?

Many thanks for suggestions/answers - I'm pulling my hair out with this.

[Rob Ingram]

Hi,

I've not aware of a requirement that a VPN must be established over a physical interface, I've don't think I've even tried on FTD.

Do you have a NAT exemption rule to ensure trafffic is not natted between the VPN peers and therefore traffic correctly matches the interesting traffic crypto ACL?

Have you turned on IKE debugs and does it even attempt to establish a VPN?

Can you run packet-tracer from the CLI and provide the output?

HTH

[nick.armitage]

Hi, yes I enabled the NAT exemption option when setting the VPN up. I did turn on the IKE debugs but didn't see any attempts. I will run a packet trace later on today as I cannot access the system right now and provide the output.

[Karsten Iwen]

As mentioned, logical interfaces are ok. Only Bridge-group-interfaces can't be used. But with them  it's not even possible to configure the VPN. The packet-tracer should give you some insight why you don't see any debugs. A very common mistake is a wrong order of the NAT-statements or a missing route to the remote network if the traffic does not follow the default-route.