Site to Site VPN Issue

the_Grinch

I've setup about 10 tunnels with various providers and thus far everything has worked. Only one is causing me grief and I'm not quite sure about the issue. My understanding was that if I setup an ACL allowing certain traffic over the tunnel (with no-nat) that on the other end they allow their local traffic to traverse the network then we're able to talk. The issue is they claim that our firewall is blocking their servers from reaching ours, even though I have it setup just as I have with other providers. Thus:

access-list PROVIDER_TUNNEL extended permit icmp <our network> 255.255.255.0 object-group <provider internal ip's>
access-list PROVIDER_TUNNEL extended permit udp <our network> 255.255.255.0 object-group <provider internal ip's> eq 1514
access-list PROVIDER_TUNNEL extended permit ip <our network> 255.255.255.0 object-group <provider internal ip's>

The above were the original acl's that worked, but then stopped thus I added the below which haven't worked

access-list PROVIDER_TUNNEL extended permit udp object-group <provider internal ip's> host <our server> eq 1514
access-list PROVIDER_TUNNEL extended permit ip object-group <provider internal ip's> <our network> 255.255.255.0

Any thoughts?

RouteMyPacket

What do debugs show? You need to run debugs and see what they tell you, you will quickly find out if there is a mismatch between the two sites.

debug crypto isakmp or debug crypto ikev1/ikev2
debug crypto ipsec

If it was working before, then something has changed and if you made no changes then well good luck trying to get the other side to admit to any changes. Have them send you a copy of their configuration for the tunnel. Is this ASA->ASA? If so, have them send you a copy of the following

sh run crypto (and send you applicable ACL thatis applied here)
sh run tunnel-group (line applicable to your side)

Most Common L2L and Remote Access IPsec VPN Troubleshooting Solutions - Cisco

phoeneous

What platform and model of both endpoints?

the_Grinch

As always thanks Route (pretty sure I owe you at least two or three beers)! Both are ASA's to the best of my knowledge (I know ours is).

the_Grinch

Hate to admit it, but according to my logs it is blocking them. So I'll start troubleshooting and hopefully fix it Thanks again guys!

d4nz1g

Make sure you've got phase 2 running
sh cry ipsec sa

With this command, you can see almost anything related to the tunnel, like send error, rcv error, or even if it has not been formed yet.

the_Grinch

The tunnel comes up and I can send packets to them, but can't receive any. According to packet tracer an acl is blocking, but even when I add an allow it still comes up as blocked. Really lost because I didn't have this issue with any of the 10 tunnels I've setup.

d4nz1g

ACL logic in a tunnel is not just a permit/deny sentence. It has to match on both ends, that forms an encryption domain.

In my opinion, you could set an acl to Permit IP net A to net B, and set an ACL in the outside interface with the explicit permissions. Just remember to turn off the "bypass outside access list", otherwise, your ACL filter will not work.

BTW, the less encryption domains you have on your tunnel, the less resources (cpu/mem) will be spent on it.

d4nz1g

Did a quick research here, and this bypass option works only for inbound IPsec sessions to the firewall (never used it before haha).

You are still able to control the traffic through nat, also.

the_Grinch

Thanks! I really think our ACLs aren't matching and that is causing the issue. I got a copy of their config and am going to reset our ACLs to match.

d4nz1g

Oh gosh, I just read what i wrote before, dont do that hahaha

Keep your tunnel as simple as possible (Network to Network), and create your traffic ACL (permit server A to server on the group policy option.

Controlling traffic through NAT is not a good solution, definetely.


access-list 101 extended permit tcp host Provider_Server host My_Server eq 80
group-policy Tunnel_Filter internal
group-policy Tunnel_Filter attributes vpn-filter value 101
tunnel-group Peer IP Add general-attributes default-group-policy Tunnel_Filter

mayhem87

If you have confirmed your IPSEC SA and see the local and remote traffic subnets/hosts are included in it:

show ipsec sa peer <provider ip> | in access-list|local|remote|encaps|decaps

Then you tunnel isn't the problem and more than likely your VPN filter. The proxy id's would have already been negotiated by then so they would have a matching acl.

Now the next part is the vpn filter. This is isn't exchanged between peers so is only looked at from you. Also ensure you have sysopt running so it uses the vpn filter and not the outside acl.

There was an error in your current acl filter:

''''''''
access-list PROVIDER_TUNNEL extended permit icmp <our network> 255.255.255.0 object-group <provider internal ip's>
access-list PROVIDER_TUNNEL extended permit udp <our network> 255.255.255.0 object-group <provider internal ip's> eq 1514
access-list PROVIDER_TUNNEL extended permit ip <our network> 255.255.255.0 object-group <provider internal ip's>

The above were the original acl's that worked, but then stopped thus I added the below which haven't worked

access-list PROVIDER_TUNNEL extended permit udp object-group <provider internal ip's> host <our server> eq 1514
access-list PROVIDER_TUNNEL extended permit ip object-group <provider internal ip's> <our network> 255.255.255.0
''''

VPN filters use reverse logic which you noted and reversed the order however your first line doesnt match.

Original
access-list 101 extended permit udp <our network> 255.255.255.0 object-group <provider internal ip's> eq 1514

Modified
access-list 101 extended permit udp object-group <provider internal ip's> host <our server> eq 1514

Should be:
access-list 101 extended permit udp object-group <provider internal ip's> eq 1514 host <our server>

RouteMyPacket

I hope you have gotten it but a rule of thumb is to first debug and parse through, is Phase 1 completing? Phase 2? if not, what are we seeing etc? If you immediately start adding/changing ACL's it begins to complicate the troubleshooting process so follow a troubleshooting pattern

Debug's aren't always ceasy to read but with some searching of the output etc you will most likely find a resolution. Again, if it was working and suddenyl stopped, I would be requesting a configuration snippit from the other end but again debug would point us to this as well.

the_Grinch

Hey guys, as always thanks! When I left the office the tunnel was up and date was flowing. We're off due to weather so I'll check Thursday or Friday to see if they are still up and data is flowing.

JeanM

Nice! What was the issue?

the_Grinch

Pretty sure it was the ACLs. I rebuilt the tunnel from scratch, then rebuilt the ACLs based off of what they had setup, and added an ACL for the outside interface. Before I left due to weather everything was reporting in except for four servers and last time they took a while to come through as well.