IPsec VPN traffic incorrectly leaving gateway not tunnel

[DavidBruce954]

Hello,

I have been attempting to create a VPN tunnel between a Cisco 2901 and PFsense router. The tunnel initiates but I only have one way traffic from the PFsense LAN network to the Cisco. On the Cisco I have no encapsulated packets. I believe I have a NAT issue. I have tried several configurations from similar posts without success. 

CONFIGURATION:

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
lifetime 28800
crypto isakmp key DOfficeaddress 2.2.2.2 no-xauth
!
!
crypto ipsec transform-set esp-aes esp-aes esp-sha-hmac
!
crypto map DOffice15 ipsec-isakmp
set peer 2.2.2.2
set transform-set esp-aes
match address VPN-TRAFFIC
!
!
!
!
!
interface GigabitEthernet0/0
no ip address
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
!
interface GigabitEthernet0/1
ip address 10.10.10.2 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
standby 100 ip 10.10.10.1
standby 100 authentication embedded
standby 100 track 1 decrement 10
!
!
interface GigabitEthernet0/2
ip address 1.1.1.1 255.255.255.248
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
crypto map DOffice
!
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip nat inside source list 100 interface GigabitEthernet0/2 overload
ip route 0.0.0.0 0.0.0.0 1.1.1.2
!
ip access-list extended VPN-TRAFFIC
permit ip 10.10.10.0 0.0.0.255 10.252.0.0 0.0.0.255
!
access-list 100 deny ip 10.10.10.0 0.0.0.255 10.252.0.0 0.0.0.255
access-list 100 permit ip 10.10.10.0 0.0.0.255 any

cisco-router-1#sh crypto ipsec sa

interface: GigabitEthernet0/2
Crypto map tag: DOffice, local addr 1.1.1.1

protected vrf: (none)
local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.252.0.0/255.255.255.0/0/0)
current_peer 2.2.2.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 6159, #pkts decrypt: 6159, #pkts verify: 6159
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 1.1.1.1, remote crypto endpt.: 2.2.2.2
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/2
current outbound spi: 0xCF9927B5(3482920885)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0x8820B68F(2283845263)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 43, flow_id: Onboard VPN:43, sibling_flags 80000046, crypto map: DGOffice
sa timing: remaining key lifetime (k/sec): (4432739/1348)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

[Georg Pauwen]

Hello,

not sure if this is a type, but your crypto map names do not match:

crypto map DOffice15 ipsec-isakmp

crypto map D2GOffice

Also, apply the crypto map to the inside interface. And since you are using HSRP, add a redundancy group. So it should look like this (on both HSRP interfaces, obviously):

interface GigabitEthernet0/1
ip address 10.10.10.2 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
standby 100 ip 10.10.10.1
standby 100 authentication embedded
standby 100 track 1 decrement 10

standby 100 name VPN_RG

crypto map DOffice redundancy VPN_RG

[Richard Burts]

It must have been a typo, now in the post the crypto map name does match.

I do not understand the suggestion about apply the crypto map to the inside interface. I have always seen the crypto map applied to the outgoing interface.

The original post suggests that there might be an issue with NAT. At this point the NAT configuration looks good to me since it does deny traffic from the inside LAN to the peer subnet and permits other traffic.

I agree that it is significant that HSRP is configured. I am wondering if the issue might be that this router is not the active router for HSRP. Would the original poster give us the output of the show command to display HSRP status.

HTH

Rick

[Georg Pauwen]

Rick,

you are probably right. Since it is HSRP, I am not sure to be honest what happens when you apply the map to BOTH the inside and the outside...

Either way, there is a setting on the PFSense side where you set the Proposal Checking to Obey, you might want to enable that, in order to avoid issues when the tunnel is initiated from the Cisco side...

[trfinkenstadt]

ip access-list extended VPN-TRAFFIC
permit ip 10.10.10.0 0.0.0.255 10.252.0.0 0.0.0.255

needs to be:

ip access-list extended VPN-TRAFFIC
permit ip host 1.1.1.1 10.252.0.0 0.0.0.255

In the packet processing of Cisco, it does nat before ipsec.  I have several of this configuration setup... Using both interface, static, and pool translations.

--tim

[Georg Pauwen]

Hello,

one more thing that might help: add 'reverse-route' to the crypto map. It apparently is necessary to support high availability site-to-Site IPSec VPNs:

crypto map DOffice 15 ipsec-isakmp
set peer 2.2.2.2
set transform-set esp-aes
match address VPN-TRAFFIC

reverse-route

[Georg Pauwen]

Hello,

can you post the config of the other HSRP router as well ?