Site to Site VPN Issue

the_Grinchthe_Grinch Member Posts: 4,165 ■■■■■■■■■■
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?
WIP:
PHP
Kotlin
Intro to Discrete Math
Programming Languages
Work stuff

Comments

  • RouteMyPacketRouteMyPacket Member Posts: 1,104
    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
    Modularity and Design Simplicity:

    Think of the 2:00 a.m. test—if you were awakened in the
    middle of the night because of a network problem and had to figure out the
    traffic flows in your network while you were half asleep, could you do it?
  • phoeneousphoeneous Go ping yourself... Member Posts: 2,333 ■■■■■■■□□□
    What platform and model of both endpoints?
  • the_Grinchthe_Grinch Member Posts: 4,165 ■■■■■■■■■■
    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).
    WIP:
    PHP
    Kotlin
    Intro to Discrete Math
    Programming Languages
    Work stuff
  • the_Grinchthe_Grinch Member Posts: 4,165 ■■■■■■■■■■
    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!
    WIP:
    PHP
    Kotlin
    Intro to Discrete Math
    Programming Languages
    Work stuff
  • d4nz1gd4nz1g Member Posts: 464
    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_Grinchthe_Grinch Member Posts: 4,165 ■■■■■■■■■■
    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.
    WIP:
    PHP
    Kotlin
    Intro to Discrete Math
    Programming Languages
    Work stuff
  • d4nz1gd4nz1g Member Posts: 464
    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.
  • d4nz1gd4nz1g Member Posts: 464
    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_Grinchthe_Grinch Member Posts: 4,165 ■■■■■■■■■■
    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.
    WIP:
    PHP
    Kotlin
    Intro to Discrete Math
    Programming Languages
    Work stuff
  • d4nz1gd4nz1g Member Posts: 464
    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 B) 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
  • mayhem87mayhem87 Member Posts: 73 ■■□□□□□□□□
    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>





  • RouteMyPacketRouteMyPacket Member Posts: 1,104
    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.
    Modularity and Design Simplicity:

    Think of the 2:00 a.m. test—if you were awakened in the
    middle of the night because of a network problem and had to figure out the
    traffic flows in your network while you were half asleep, could you do it?
  • the_Grinchthe_Grinch Member Posts: 4,165 ■■■■■■■■■■
    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.
    WIP:
    PHP
    Kotlin
    Intro to Discrete Math
    Programming Languages
    Work stuff
  • JeanMJeanM Member Posts: 1,117
    Nice! What was the issue?
    2015 goals - ccna voice / vmware vcp.
  • the_Grinchthe_Grinch Member Posts: 4,165 ■■■■■■■■■■
    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.
    WIP:
    PHP
    Kotlin
    Intro to Discrete Math
    Programming Languages
    Work stuff
Sign In or Register to comment.