VPN passthrough

[jerryv]

Hi, we're experiencing issue with site-to-site connectivity since we installed PAN firewall in the network few days ago. There are many IPSec (ikev1) tunnels configured between endpoints on the internet and Cisco VPN concentrator (ISR 4k router) behind the PAN firewall. Only 2 specific sites can't establish IPsec connection anymore since PAN has been installed in the prodution. Network diagram before PAN was installed in the network: customer linux server with openswan - (private IP) - customer router with NAT 1:1 - ##internet## - router - (pub IP) - VPN concentrator Network diagram after PAN has been installed: customer linux server with openswan - (private IP) - customer router with NAT 1:1 - ##internet## - router - (pub IP) - PAN firewall - (pub IP) - VPN concentrator Logs on Cisco ISR: *Jan 27 20:30:31.891: ISAKMP-PAK: (1468):sending packet to 191.84.85.31 my_port 500 peer_port 500 (R) MM_KEY_EXCH *Jan 27 20:30:31.891: ISAKMP: (1468):Sending an IKE IPv4 Packet. *Jan 27 20:30:31.891: ISAKMP: (1468):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Jan 27 20:30:31.891: ISAKMP: (1468):Old State = IKE_R_MM3 New State = IKE_R_MM4 *Jan 27 20:30:33.440: ISAKMP: (1080):purging node 2651156776 *Jan 27 20:30:41.891: ISAKMP: (1468):retransmitting phase 1 MM_KEY_EXCH... *Jan 27 20:30:41.891: ISAKMP: (1468):: incrementing error counter on sa, attempt 1 of 5: retransmit phase 1 There is access policy configured on PAN that permits "any" application, "any service" between zones/ip addresses. It seems there is some traffic blocked by PAN. I run packet capture with filters defined (public IP addresses of both endpoints) and there were some NAT-T (udp/4500) packets dropped in the "drop" packet capture file. I configured one linux server with openswan for testing purposes and assigned public IP address on the network adapter. IPsec tunnel was established without any problem. I tried to lower MTU (1300) on outside interface but it didn't solve the problem. Does anyone have any idea what could be wrong?

[reaper]

Have you verified why the packet was in the drop stage? you can follow global counters while you're doing packetcaptures:

> show counter global filter delta yes packet-filter yes

This will show why packets may get discarded (also, traffic logs or threat logs may help shed light on what's going on)

[jerryv]

Hi, thanks for the hint. I found one counter with severity=drop: zonechange: flow_fwd_zonechange 2 0 drop flow forward Packets dropped: forwarded to different zone Customer is connecting from "outside" (only default route matches), DMZ, where site-to-site VPN concentrator is installed is using "connected" route. There are only static routers configured on PAN. There is no NAT configured for DMZ zone. Firewall rule permits any traffic (I tried with app-default, all tcp+udp ports...). Packet capture shows dropped packets (stage=dropped) with customers public IP address as originating IP address and with our site to site VPN concentrator's public IP address as the destination IP address. Could you please give me a hing how can I diagnose the root cause of the issue?

[jerryv]

Hi, I found one interesting info: show session all filter from OUTSIDE source 191.84.85.31 38 ipsec-esp-udp ACTIVE FLOW 191.84.85.31[4500]/OUTSIDE/17 (191.84.85.31[4500]) vsys1 81.29.27.52[4500]/OUTSIDE (81.29.27.52[4500]) 4220 ike ACTIVE FLOW 191.84.85.31[500]/OUTSIDE/17 (191.84.85.31[500]) vsys1 81.29.27.52[500]/DMZ (81.29.27.52[500]) There are two different zones detected for same connection flow: OUTSIDE (wrong) and DMZ (correct). Zone configuration only includes interface name. Strange...

[reaper]

can you include a network design and what your routing table looks like?

there may be overlap in your IP subnets on your interfaces, or irregularities in your routing table

[jerryv]

Hi, here is the network diagram

design

design

design

[reaper]

that looks more straight forward than I had expected 🙂

So your firewall has 1 interface 88.200.12.2/30, one interface 81.29.27.33/27, the static routing table is 0.0.0.0/0 -> 88.200.12.1

Then a security policy any any accept, no nat ?

Ah but wait, it's the same ISR4K providing the ipsec endpoint that also provides your WAN routing ?

could it be it is performing som einternal routing and some packets may be egressing on the opposite side of the firewall ?

[jerryv]

Hi, there are two different ISR routers installed.

There is not NAT configured between OUTSIDE and DMZ.

[Brandon_Wertz]

Any chance you're running < 8.0.7 code?

[jerryv]

Hi, no, we're running 8.0.7.