11-28-2018 01:21 PM - edited 11-30-2018 06:06 AM
Dear all,
I'm currently working to establish a VPN tunnel with VTI between a Cisco ASA and PFsense.
I'm the owner of the ASA but not of the Pfsense box.
Cisco ASA is 5525-X running the 9.9.1 in failover mode
Let me 1st share with you the topology:
Basically from ASA perspective, the tunnel interface is up and running and I can ping the remote tunnel interface.
This is the tunnel interface configuration:
tunnel 10
nameif vti-10
ip address 172.20.244.209 255.255.255.252
tunnel source interface outside
tunnel destination a.b.c.d
tunnel mode ipsec ipv4
tunnel protection ipsec profile MYPROFILE
I have a static route on my ASA:
route vti-10 192.168.1.0 255.255.255.0 172.20.244.210
So ping OK from 172.20.244.209 to 172.20.244.210
But from my private subnet to the remote private subnet it is not the case.
So ping NOT from 192.168.0.20 to 192.168.1.20
I made captures and packet-tracer and I found very interresting things.
The packet-tracer shows that the packet is dropped with reason: No valid adjacency
The inside capture shows that the packet comes into the ASA via the inside interface.
Phase: 14
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f9cf2519c70, priority=0, domain=inspect-ip-options, deny=true
hits=208443, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 15
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.20.244.210 using egress ifc vti-10
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: vti-10
output-status: up
output-line-status: up
Action: drop
Drop-reason: (no-adjacency) No valid adjacency
The asp-drop capture shows that the packet is really dropped.
And the debug arp shows that ASA is sending arp request asking who is the remote tunnel peer.
arp-req: generating request for 172.20.244.210 at interface vti-10
arp-send: arp request built from 172.20.244.209 0000.0000.0000 for 172.20.244.210 at 17:12:49.015
arp-send: arp request built from 172.20.244.209 0000.0000.0000 for 172.20.244.210 at 17:12:50.065
arp-req: generating request for 172.20.244.210 at interface vti-10
arp-req: request for 172.20.244.210 still pending
arp-send: arp request built from 172.20.244.209 0000.0000.0000 for 172.20.244.210 at 17:12:51.065
arp-req: generating request for 172.20.244.210 at interface vti-10
arp-req: request for 172.20.244.210 still pending
arp-req: generating request for 172.20.244.210 at interface vti-10
arp-req: request for 172.20.244.210 still pending
arp-send: arp request built from 172.20.244.209 0000.0000.0000 for 172.20.244.210 at 17:12:55.065
arp-req: generating request for 172.20.244.210 at interface vti-10
arp-req: request for 172.20.244.210 still pending
arp-send: arp request built from 172.20.244.209 0000.0000.0000 for 172.20.244.210 at 17:13:00.065
What is the reason for the ASA to send arp request? We are talking about tunnel , so for me this is not a normal behavior.
Hopping that someone can help me.
Thank you
IMO
11-30-2018 05:52 AM
11-30-2018 06:07 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide