cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1007
Views
0
Helpful
2
Replies

VTI VPN - problem

Isidore Moreno
Level 1
Level 1

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:

Topology.jpg


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

2 Replies 2

JP Miranda Z
Cisco Employee
Cisco Employee
Hi Isidore Moreno,

Not sure if this is just a typo here but your static route is pointing to the wrong next hop:

route vti-10 192.168.1.0 255.255.255.0 172.20.244.10

as far as i understand should be: 172.20.244.210

Hope this info helps!!

Rate if helps you!!

-JP-

Hi JP,

Yes it is…
I have just modified the content.

Thanks for your feedback,

Isidore