One way traffic over the VPN tunnel

[Jean Paul Enerst]

Hi Pros,

                  We are having issue with traffic going through the VPN. A specific subnets isn't able to reach a specific HOST in the HQ, however, the host in the HQ can reach that subent at the remote. Interresting traffic for vpn  are mirrored of each other. Below is the partial config of the remote vpn router.

crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key mypubkey9 address 210.199x.2xx.xx
!
!
crypto ipsec transform-set vpn-set esp-3des esp-sha-hmac
!
crypto map tunel_traffic 50 ipsec-isakmp
set peer 210.199x.2xx.xx
set security-association lifetime seconds 1440
set transform-set vpn-set
set pfs group2
match address remote-int-traffic
!
!
!
!
interface Null0
no ip unreachables
!
interface FastEthernet0/0
ip address 1.1.1.3 255.255.255.248
   ip virtual-reassembly
ip route-cache flow
speed 100
full-duplex
no mop enabled
!
interface FastEthernet0/1
ip address 10.25.24.2 255.255.255.0
  ip nat outside
ip inspect SDM_LOW out
ip virtual-reassembly
speed 100
full-duplex
no mop enabled
crypto map tunel_traffic
!
ip route 0.0.0.0 0.0.0.0 10.25.24.2
ip route 1.0.10.0 255.255.255.0 210.199x.2xx.xx(Public IP of the HQ vpn router)
ip route 4.0.x.0 255.255.255.0 210.199x.2xx.xx
ip route 4.0.15.11 255.255.255.255 210.199x.2xx.xx ( can't reach this hot at the HQ)
ip route 10.254.0.0 255.255.255.0 210.199x.2xx.xx
ip route 10.254.254.56 255.255.255.255 210.199x.2xx.xx
!

ip access-list extended remote-int-traffic
permit ip host 10.254.254.56 10.1x.200.0 0.0.3.255
permit ip 10.1x.200.0 0.0.3.255 host 10.254.254.56
permit ip 10.1x.20.0 0.0.3.255 host 10.254.254.5
permit ip host 4.0.x.11 10.1x.200.0 0.0.3.255
permit ip 10.1x.200.0 0.0.3.255 host 4.0.x.11
!

Thanks

[mikull.kiznozki]

what is the dg on the host at the spoke site?

do you notice encryptions when u do a sh cry ipsec sa while testing from spoke to hub?

[Jean Paul Enerst]

Thanks for the reply. I haven't ran a debug on the HQ router yet(too busy, it might crash). Howvwer, Wireshark in front of the HQ router shows that the packets did not get to HQ router! Usually, on way traffic is either routing or interresting traffic in the ACL. In case cases, i have a summarize  route as per below(remote from the first subnet in the summarize(10.1x.200.0/23) can't ping that host in HQ, but other subnet can).  And i also have a static router pointed to HQ public IP.

Thx

[Jennifer Halim · Accepted solution]

You don't really need to configure any of the following routes, and it looks incorrect as it should really be pointing towards the router next hop. It should just route via the default route if you only have the listed routes configured. Pls remove them if those are all you have configured and left the default route in the configuration.

ip route 1.0.10.0 255.255.255.0 210.199x.2xx.xx(Public IP of the HQ vpn router)

ip route 4.0.x.0 255.255.255.0 210.199x.2xx.xx

ip route 4.0.15.11 255.255.255.255 210.199x.2xx.xx ( can't reach this hot at the HQ)

ip route 10.254.0.0 255.255.255.0 210.199x.2xx.xx

ip route 10.254.254.56 255.255.255.255 210.199x.2xx.xx

Also, if it works one way, it is most probably an access-list or firewall that blocks the traffic in one direction.

[Jean Paul Enerst]

Jen,

         You are correct about the route, but this isn't the issue. Also the vpn router only has ACL for interresting traffic to go throught the tunnel.

As mentioned below, packet snif inb front of the HQ vpn router prooves that the packet do not get to the HQ. At the same time trace from host on the affected subnet shows that the last hope is the remote VPN remote.

Yes, there is a pix firewall at the remote... but it does not block trajet going the subnet... I will post this FW config shortly.

Thanks,

[Jennifer Halim]

When you sniff the packet, I assume that you are sniffing the VPN traffic (ESP), as it would still be encrypted if you sniff it in front of the HQ vpn router.

Ahhh, and btw, just realise that your crypto ACL doesn't look right. It should just be in one direction, not both as configured.

ip access-list extended remote-int-traffic

permit ip 10.1x.200.0 0.0.3.255 host 10.254.254.56

permit ip 10.1x.20.0 0.0.3.255 host 10.254.254.5

permit ip 10.1x.200.0 0.0.3.255 host 4.0.x.11

You should only have the above 3 lines configured, and on the remote end, it should also have just 3 lines, and it should mirror image.

The remote end should have:

ip access-list extended remote-int-traffic

permit ip host 10.254.254.56 10.1x.200.0 0.0.3.255

permit ip host 10.254.254.5 10.1x.20.0 0.0.3.255

permit ip host 4.0.x.11 10.1x.200.0 0.0.3.255

Otherwise, you would find all sorts of weird issues. Pls make the necessary modifications, clear the tunnels (clear cry ipsec sa, and clear cry isa sa) so the new ACL can be negotiated.

[Jean Paul Enerst]

Jen,

           Thanks again for the help. I did sniff the packets at a location where i was able to see un encrypted traffic just after tyhe HQ router decrypt them(ping traffic from remote to HQ 10.254.254.56). And yes, i was able to see encrytped traffic as going to the other side well.

And yes, i am totally agree with on the crypto ACL, i just herited this from a previous admin. I guess it just created the crypto map and pasted the same one at both end....It's lazy to do so, but it does save which we don't often have enough of in the IT world, so i can blame him!  Yes, that he is the plan to remove unnecessary ACL,but i had to do that after hours.

Thanks,

[Jennifer Halim]

Ahh, do you mean that it does arrive on the HQ router and get decrypted, however, there is no reply from the actual host?

Can you pls share the output of:

show cry ipsec sa

Also, as Mikul advised earlier, is the default gateway of the host set correctly to point back towards the HQ router? and/or does it have a host firewall that might prevent inbound connections?