cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10591
Views
5
Helpful
19
Replies

Newbie to VPN - Cisco Router to pfSense IPSec problems

Brett Tesdall
Level 1
Level 1

Hi, everyone,

I'm still in the process of learning about Cisco, but I'm now tasked with a problem that I'm stuck on and up against a time limit to fix.

At our home office, we have a pfSense box providing IPSec tunnels to some remote locations and these are working fine.  We're now setting up a new remote office and we're wanting to put a Cisco 1921 there as the IPSec endpoint because a couple of months from now, we hope to have this location added to our MPLS and the Cisco should be able to handle that.  Temporarily, we'll be having a cable modem connection to provide Internet service and want to VPN back to the home office as well as provide general Internet services for the office people.

Right now, my connection to the remote office LAN is on G0/0 of the 1921.  It has an IP of 10.23.10.1 and is providing DHCP services to the LAN.  I have plugged a computer into G0/0 and confirmed DHCP is working.  The 1921 is currently in our home office while I set it up, so for testing, I plugged a cable into G0/1 that was for an outside connection to the Internet.  In this configuration, I was able to confirm that my test computer could get out to the internet through the 1921 after I added a default static route.  So, at this point, everything seemed to be working fine.

Then I began to working on the VPN between the Cisco and pfSense using this article as a guide:  https://doc.pfsense.org/index.php/IPsec_between_pfSense_and_Cisco_IOS   For the most part this worked, although I made an error in the Phase 2 portion, but thought I had it fixed.  However, while the tunnel does appear to be established, no traffic is passing.  Also, no Internet traffic is passing either, so this is clearly not doing a split-tunnel.

This is what the debug for IPSec is showing:

*Feb 18 15:56:09.987: IPSEC(validate_proposal_request): proposal part #1
*Feb 18 15:56:09.987: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 205.237.121.4:0, remote= 205.237.121.1:0,
    local_proxy= 10.23.0.0/255.255.240.0/256/0,
    remote_proxy= 10.0.0.0/255.248.0.0/256/0,
    protocol= ESP, transform= NONE  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Feb 18 15:56:09.987: Crypto mapdb : proxy_match
        src addr     : 10.23.0.0
        dst addr     : 10.0.0.0
        protocol     : 0
        src port     : 0
        dst port     : 0
*Feb 18 15:56:10.039: IPSEC(key_engine): got a queue event with 1 KMI message(s)
*Feb 18 15:56:10.039: Crypto mapdb : proxy_match
        src addr     : 10.23.0.0
        dst addr     : 10.0.0.0
        protocol     : 256
        src port     : 0
        dst port     : 0
*Feb 18 15:56:10.039: IPSEC(crypto_ipsec_create_ipsec_sas): Map found PFSVPN
*Feb 18 15:56:10.039: IPSEC(create_sa): sa created,
  (sa) sa_dest= 205.237.121.4, sa_proto= 50,
    sa_spi= 0xDB886A86(3683150470),
    sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2007
    sa_lifetime(k/sec)= (4608000/3600)
*Feb 18 15:56:10.039: IPSEC(create_sa): sa created,
  (sa) sa_dest= 205.237.121.1, sa_proto= 50,
    sa_spi= 0x73DE9E8(121498088),
    sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2008
    sa_lifetime(k/sec)= (4608000/3600)
*Feb 18 15:56:10.043: IPSEC(key_engine): got a queue event with 1 KMI message(s)
*Feb 18 15:56:10.043: IPSEC(key_engine_enable_outbound): rec'd enable notify from ISAKMP
*Feb 18 15:56:10.043: IPSEC: Expand action denied, notify RP

So, at this point, I'm a bit stuck as to what's wrong.  First, I need to get the VPN working and passing traffic.  Secondly, I need to configure this as a split-tunnel so only traffic destined for the home office goes over the VPN and everything destined for the Internet does not.

 

Any suggestions?  I'm attaching the config for the 1921.

Thanks!

 

Brett

 

P.S.  Just one note about the config....At our home office, we have multiple subnets in the 10.x.x.x ranges.  We want traffic that is destined for any of them to traverse the VPN.

1 Accepted Solution

Accepted Solutions

Hi Brett,

 

If you have changed on the router on the ACL 100, from 10.0.0.0/8 to 10.0.0.0/13, then you also have to change it on ACL 101 as well for deny line.

 

no access-list 101 deny   ip 10.23.10.0 0.0.0.255 10.0.0.0 0.255.255.255

 

access-list 101 deny  ip 10.23.10.0 0.0.0.255 10.0.0.0 0.7.255.255

 

Let me know, if this helps.

 

Thanks

Rizwan Rafeek.

View solution in original post

19 Replies 19

rizwanr74
Level 7
Level 7

Please change this lines.

 

 

no ip nat inside source list 1 interface GigabitEthernet0/1 overload
!
access-list 1 permit 10.23.10.0 0.0.0.255
no access-list 100 permit ip 10.0.0.0 0.255.255.255 10.23.10.0 0.0.0.255
access-list 100 permit ip 10.23.10.0 0.0.0.255 10.0.0.0 0.255.255.255
no access-list 100 permit ip 10.0.0.0 0.255.255.255 10.23.0.0 0.0.15.255
access-list 100 permit ip 10.23.0.0 0.0.15.255 10.0.0.0 0.255.255.255
!

 

access-list 101 deny ip 10.23.0.0 0.0.0.255 10.0.0.0 0.255.255.255

access-list 101 permit ip 10.23.0.0 0.0.15.255 any

 

ip nat inside source list 101 interface GigabitEthernet0/1 overload

 

Let me know, if this helps.

Thanks

Rizwan Rafeek

Hi, Rizwan,

I have made the changes you indicated.  I can ping my LAN-side machine and the public IP of the pfSense box at the other end of the VPN, however I am unable to ping something on the Internet and still unable to ping anything on the other side of the VPN tunnel.  

I'm also now getting this on the IPSec debug:

*Feb 18 17:38:54.647: IPSEC(validate_proposal_request): proposal part #1
*Feb 18 17:38:54.647: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 205.237.121.4:0, remote= 205.237.121.1:0,
    local_proxy= 10.23.0.0/255.255.240.0/256/0,
    remote_proxy= 10.0.0.0/255.248.0.0/256/0,
    protocol= ESP, transform= NONE  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*Feb 18 17:38:54.647: IPSEC(ipsec_process_proposal): proxy identities not supported

 

Do I need to make adjustments on the pfSense end?  The networks I have on the other end are 10.0.0.0/13 (local) and 10.23.0.0/20 (remote).  I did have this problem before and it seemed to be a mismatch here.

 

If you internal segment is on this subnet : 10.23.0.0 0.0.15.255 any  or 10.23.10.0 0.0.0.255?

 

If you say "10.23.10.0 0.0.0.255"

 

then remove this line:

no access-list 101 permit ip 10.23.0.0 0.0.15.255 any

 

 

add after deny line.

access-list 101 permit ip 10.23.10.0 0.0.0.255 any

 

Let me know if this helps.

 

thanks

 

 

 

 

You have to match from both sides, remote subnet and local subnet for phase 2 negotiation.

On pfSense, I changed the remote network to 10.23.10.0/24 and in the Cisco, the access-list is as shown:

 

access-list 101 permit ip 10.23.10.0 0.0.0.255 any

These should match, shouldn't they?

For the local network on the pfSense box, it is listed as 10.0.0.0/13, but I don't see an entry that matches in the Cisco now.  Should I add this:

Access-list 101 permit ip 10.0.0.0 0.255.255.255 any

 

Access-list 101 must deny traffic that are tunnel bound and you only permit at the bottom subnet that needed access to Internet.

 

So you deny your internal "10.23.10.0 0.0.0.255" to remote segment "10.0.0.0 0.255

.255.255" for ACL 101.

 

However you permit "10.23.10.0 0.0.0.255" accessing your remote lan segment "10.0.0.0 0.255.255.255" for access-list 100.

 

Otherwise make life easy for you, please define your local segment need access to remote land segment.

 

Please post your most current config.

thanks.

 

 

 

OK, so if I'm understand, access-list 101 is for Internet access, yes?

So, then I should take access-list 101 off the Crypto map PFSVPN.  What do I replace it with so the tunnel will work and pass only traffic destined for our home office?  In the home office, we have these subnets amongst others:

10.3.3.x

10.5.5.x

10.6.6.x

10.8.8.x

We want those subnets to be accessible via the VPN, which is what the 10.0.0.0 0.255.255.255 access-list was meant to do.  Should I create a new access-list for this?

Made some changes and posting latest config.

"So, then I should take access-list 101 off the Crypto map PFSVPN" Yes

 

"What do I replace it with so the tunnel will work and pass only traffic destined for our home office? " Use access list 100 instead.

access-list 100 permit ip 10.23.10.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 100 permit ip 10.23.10.0 0.0.0.255 10.0.0.0 0.255.255.255

 

I assume this is your local segment 10.23.10.0/24

 

Match acl 100 from other end of the tunnel.

 

thanks

 

 

Please see my current config.  I still have no traffic passing through the VPN or going out to the Internet.  I thought the VPN problem might have been because a rule was missing on the pfSense's firewall and traffic was being blocked at the home office end, but we've added an allow rule and it's still not working.

 

Brett

 

Hi Brett,

Please remove this below line on router:  RTR-MPLS-Devens

no access-list 100 permit ip 10.0.0.0 0.255.255.255 10.23.10.0 0.0.0.255


Everything else is fine on RTR-MPLS-Devens.

 

Now please make sure your remote tunnel peer configured as shown below.

 

access-list 100 permit ip 10.0.0.0 0.255.255.255 10.23.10.0 0.0.0.255

 

thanks

I do not have a Cisco device on the other end of this tunnel from the 1921.  The other endpoint is a pfSense box, that as far as I can tell, is configured correctly, but no traffic is passing and I still have no Internet connectivity from my test workstation or from the 1921 router itself.

 

Any other ideas??

Do I need to have some ip route statements in here somewhere?  The routing shows this:

 

RTR-MPLS-Devens#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.23.10.0/24 is directly connected, GigabitEthernet0/0
L        10.23.10.1/32 is directly connected, GigabitEthernet0/0
      205.237.121.0/24 is variably subnetted, 2 subnets, 2 masks
C        205.237.121.0/24 is directly connected, GigabitEthernet0/1
L        205.237.121.4/32 is directly connected, GigabitEthernet0/1

You can manually add a static route to your default gateway address as shown below.

 

ip route 0.0.0.0 0.0.0.0 205.237.121.254

 

If this does not help, please post your debug output.

Thanks

PROGRESS!

From my test machine, I'm now able to ping to a public IP address.  I did have this in my config at one time, but might have removed it because of the VPN problems.

However, I'm still unable to ping anything in the 10.x.x.x subnets on the other side of the tunnel.

Is there anything else I can do to debug this?

 

You must confirm with remote tunnel administrator that he or she is permitting traffic for encryption domain looks like this: "10.0.0.0 0.255.255.255 10.23.10.0 0.0.0.255" that is exactly look like this.

 

You can enable debug.

debug crypto isakmp

debug crypto ipsec

 

Thanks

 

 

Review Cisco Networking for a $25 gift card