Trying to get the VPN in this Cisco Pix to work w/ pfsense.

[ElementalWindX]

I'm using PFSense 2.1 beta snapshots

I'm having an issue with this pfsense that is load balancing 2 wan's on this network. There is a cisco pix on this network that needs to be able to show its connecting only thru WAN A, and it's trying to connect on both WAN A and B. Unfortunately I cannot touch the pix as it's dealing with the server vendor we have to use. This is the email he sent me trying to figure out how to fix this issue.


This is in regards to the VPN Tunnel that is down. We have a PIX Firewall using WAN IP 192.168.168.1, that should be NAT’d to WAN A to establish the IPSEC tunnel. I’m seeing this IP change from WAN A to WAN B. You need to make sure that you’re Natting us only to WAN A. Also, be sure there is no filtering/blocking port 500 for IPSEC.



I'm trying to figure out exactly how to accomplish this. In the port forward section I have added a rule as such: If WAN A, Proto TCP/UDP, src *, dest *, dest port 500, nat ip 192.168.168.1 nat ports * . I've told it to reflect this port in the rules and it does.

I've also added a rule in the firewall rules under LAN for any tcp/udp with port 500 to go thru gateway WAN A.



They still cannot seem to get the vpn to connect. They say it is timing out. :/

The IP of the pfsense is 192.168.168.168
I ping the ip 192.168.168.1 on LAN and I get a response...

PING 192.168.168.1 (192.168.168.1) from 192.168.168.168: 56 data bytes
64 bytes from 192.168.168.1: icmp_seq=0 ttl=255 time=0.181 ms
64 bytes from 192.168.168.1: icmp_seq=1 ttl=255 time=0.102 ms
64 bytes from 192.168.168.1: icmp_seq=2 ttl=255 time=0.102 ms

--- 192.168.168.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.102/0.128/0.181/0.037 ms




Apparently this is a site to site vpn tunnel. Not quite sure how I can test whether this is working or not without calling them over and over and asking "does it work now?"


*edit* I've even setup a rule in the firewall rules saying any data coming from 192.168.168.1 will go out on WAN A, and they still say it does not work. :/ wtf?

 

[ComputerPro]

Are you using 192.168.168.0 /24
Or literally the IP address .1 in your rules? Just curious.

 

[ElementalWindX]

Are you using 192.168.168.0 /24
Or literally the IP address .1 in your rules? Just curious.

just .1, not the entire subnet.

 

[ComputerPro]

It's been a while, but don't you need the subnet specified in your rules? How are LAN IPs going to talk across the VPN? Are they encapsulated with .1 and NAT'd to the PC? Seems like the tunnel would up but no traffic would cross since the rules would drop those packets unless they matched .1

It's been a while for me, maybe someone who works with VPNs every day can chime in.

 

[SouthernTech]

VPNs are built in 2 phases. Phase 1 is the initial establishing of the end points. Generally, these are the interfaces of the termination point. Once the gateways are established, phase 2 can be begin and the tunnels can be built. Tunnels are the local resources to be shared across the VPN. Typically, port 500 is used for the IKE, but port 4500 might also be used for NAT traversal(NAT-T), if there are other devices along the way that need to NAT again. It is very important to know where the negotiations are failing.

1) What are the gateway endpoints?
2) I see that your local tunnel resource is 192.168.168.0 /24. However, what is the remote tunnel resource? If the remote side has the same private IP address range as the local side, you will run into routing issues. Generally, you have to do a 1:1 NAT between to get around this.
3) A tracert to the other side of the tunnel would go out the gateway IP and then hit the remorte resource. If the tunnel is not build and you attempt to tracert a private IP address that is not known, it will time out going to the internet.

 

[teksquad]

Ipsec uses udp port 500 (ISAKMP - Phase1) and protocol 50 for ESP (actual encrypted traffic - Phase2 - This is not port 50 but protocol 50) Will also use udp 4500 if NAT-T is detected in the path as well. If they are still using a pix then they really need to upgrade it to an ASA as pix code is very old.

On cisco devices remember that NAT happens before encryption so If you are natting then you need to specify the post nat address in your crypto ACL's. Make sure that phase 1 and phase 2 parameters are the same on both sides of the tunnel. They should be mirror images of each other. Without looking at the pix config and some kind of diagram then it will be hard to troubleshoot this any further.


show crypto isakmp sa (Check Phase 1)

Should show QM_IDLE or MM_ACTIVE (I think the pix shows it as QM_IDLE as the ASA shows it as MM_ACTIVE)

show crypto ipsec sa (Check Phase 2)

Here you are looking for traffic being encapsulated and encrypted (sending) and decap and decrypted (receiving)


#pkts encaps: 1807, #pkts encrypt: 1807, #pkts digest: 1807
#pkts decaps: 6479, #pkts decrypt: 6636, #pkts verify: 6636

If you don't have local access to the pix then you need to ask your provider to check this for you.

 

[ElementalWindX]

Ipsec uses udp port 500 (ISAKMP - Phase1) and protocol 50 for ESP (actual encrypted traffic - Phase2 - This is not port 50 but protocol 50) Will also use udp 4500 if NAT-T is detected in the path as well. If they are still using a pix then they really need to upgrade it to an ASA as pix code is very old.

On cisco devices remember that NAT happens before encryption so If you are natting then you need to specify the post nat address in your crypto ACL's. Make sure that phase 1 and phase 2 parameters are the same on both sides of the tunnel. They should be mirror images of each other. Without looking at the pix config and some kind of diagram then it will be hard to troubleshoot this any further.


show crypto isakmp sa (Check Phase 1)

show crypto ipsec sa (Check Phase 2)

Completely forgot about protocol 50. I definitely agree about the pix being wayyyy too old. You should see the rest of the equipment.

I've attached screenshots of the current natting and rules setup. Let me know what you think.

GW_OPT1 is the timewarner connection I need it to go out on.

 

[teksquad]

Is the pix terminating the vpn or is the PFSense? By default transit traffic through the pix is subject to ACL checks (including your IPSEC traffic) so if the PFSense or another device behind the pix is terminating the vpn then you would need ACL entries allowing ISAKMP, ESP and/or NAT-T (UDP 4500) traffic coming inbound. If the pix is terminating one end of the vpn then depending on the version of code you may or may not have to specify ACL entries for said traffic.

sysopt connection permit-vpn command lets any ISAKMP/IPSEC traffic come inbound regardless of any ACL's configured on the outside interface. This only applies to traffic destined to the pix though (IE If the pix is the endpoint of the tunnel and does not apply to transit traffic)

I never messed with PFSense so I cant help you there. Posting a good diagram with the proper addressing and layout would help alot though. You really need access to the pix to check logs though to see if anything is being blocked or filtered.

 

[teksquad]

Also wanted to add if the pix is using older code like 6.3 then a NAT rule is required for any traffic to be forwarded. This can be accomplished with a nat exemption rule or policy based nat. If this is not done then traffic will be dropped. Again without seeing the pix config I cant tell if this is there or not. I know it sounds weird because it looks like your PFSense is doing nat but the earlier versions of the pix required a NAT rule in place even if it was just an exception rule.

Normally you would exempt any traffic between the vpn remote networks


access-list NO_NAT permit ip 10.10.10.0 255.255.255.0 10.10.11.0 255.255.255.0

nat (inside) 0 access-list NO_NAT

This say that anything coming in the inside interface sourced from 10.10.10.0/24 and going to 10.10.11.0/24 - Dont NAT it. This is assuming that the vpn remote networks are 10.10.10.0/24 and 10.10.11.0/24.

PIX code 7.0 and above allow you to turn this NAT requirement off with the

no nat-control command.

In newer ASA versions such as 8.1 and above nat control is off by default


Can you verify that Phase1 is even up? If not then thats where you need to start troubleshooting. If phase 1 is up and phase 2 is failing then you need to check those parameters. Also check to make sure that the ACL's are allowing the appropriate traffic inbound on the outside interface of the pix if needed. If the sysopt connection permit-vpn command is available then you can use that to permit the required vpn traffic inbound without having to manually configure your ACL's.

Are you using a dedicated ip for the vpn? This makes things much easier as you only need a 1 to 1 translation and not PAT.

You really need to look at the pix to check phase 1 and phase 2 issues.

 

[SouthernTech]

As Teksquad said, we would need a full diagram of both sides to properly troubleshoot. Cisco devices can also send their domain name instead of their IP, but I don't think it will be an issue in this case.

Something like this, there should be traffic logs indicating where the failure is at.

 

[ElementalWindX]

Also wanted to add if the pix is using older code like 6.3 then a NAT rule is required for any traffic to be forwarded. This can be accomplished with a nat exemption rule or policy based nat. If this is not done then traffic will be dropped. Again without seeing the pix config I cant tell if this is there or not. I know it sounds weird because it looks like your PFSense is doing nat but the earlier versions of the pix required a NAT rule in place even if it was just an exception rule.

Normally you would exempt any traffic between the vpn remote networks


access-list NO_NAT permit ip 10.10.10.0 255.255.255.0 10.10.11.0 255.255.255.0

nat (inside) 0 access-list NO_NAT

This say that anything coming in the inside interface sourced from 10.10.10.0/24 and going to 10.10.11.0/24 - Dont NAT it. This is assuming that the vpn remote networks are 10.10.10.0/24 and 10.10.11.0/24.

PIX code 7.0 and above allow you to turn this NAT requirement off with the

no nat-control command.

In newer ASA versions such as 8.1 and above nat control is off by default


Can you verify that Phase1 is even up? If not then thats where you need to start troubleshooting. If phase 1 is up and phase 2 is failing then you need to check those parameters. Also check to make sure that the ACL's are allowing the appropriate traffic inbound on the outside interface of the pix if needed. If the sysopt connection permit-vpn command is available then you can use that to permit the required vpn traffic inbound without having to manually configure your ACL's.

Are you using a dedicated ip for the vpn? This makes things much easier as you only need a 1 to 1 translation and not PAT.

You really need to look at the pix to check phase 1 and phase 2 issues.

I wish I could access that pix This is dealing with ADP dealer services. All their equipment is out dated and their methods are so old it makes my grandma look like a pre-teen. You mention the word fail over to them and they act like Homer Simpson.


The pix is terminating the vpn.


I might try doing it in this method as the pfsense in older versions is said to not be able to handle ipsec traffic correctly. I am using the newest beta though.


twc -> pix -> pfsense ---> network
earthlink --> pfsense ---> network


I think that might work just fine as they are using the pix more for remote vpn access for support/troubleshooting than they are for security measures.

 

[teksquad]

Agreed the best place to start is on the pix itself. If you dont have access to it then the provider needs to look at the logs and configuration. There is no reason to change anything else at this point as the problem could be on the pix itself. Not having access to devices in these kind of cases is a pain in the a** as you rely on someone else.

 

[teksquad]

I think that might work just fine as they are using the pix more for remote vpn access for support/troubleshooting than they are for security measures.

If this is the case i would have them pull out the pix and replace it with an ASA (or you add it that way you have control of it) and just use SSL VPN with the anyconnect client for remote access. You get 2 free licenses with the ASA.

 

[ElementalWindX]

If this is the case i would have them pull out the pix and replace it with an ASA (or you add it that way you have control of it) and just use SSL VPN with the anyconnect client for remote access. You get 2 free licenses with the ASA.

I wish. They won't hardly work with me on anything. I'm lucky if I can get them to change the wan IP on the pix itself. They want to charge an arm and a leg to make any changes at all.


I realized I had some extra public ip's I am not using so what I've done so far is added some virtual IP's on the pfsense.

I'll try to explain it as best as possible.
I've attached a poorly made mspaint pic to show the network layout.


24.1.1.1 is WAN A
1.1.1.1 is WAN B
1.1.1.2 is WAN B2 (Virtual)
1.1.1.3 is WAN B3 (Virtual)
192.168.168.* is LAN in the PFSense
192.168.168.1 is the ip of the PIX on the "WAN" side.
206.93.9.* is LAN in the Cisco Router
Currently all the computers act like the Cisco Router is the gateway and are on that 206 network.

I've setup a 1:1 nat to go from WAN B2 strictly to the pix (192.168.168.1)
I've setup port forwards and rules in the pfsense to direct only 500/4500/ESP traffic to go to and from 192.168.168.1


The VPN works. Traffic is load balancing. But I am unsure as to how stable this will be. We power cycled everything and tried to break it and it kept coming back up.

However traffic on the network when browsing the web is using the WAN B2 address sometimes instead of the WAN address. Why? I'm guessing my 1:1 nat rule, saying all traffic from the clients/server etc must be coming to the pfsense looking like 192.168.168.1 sooo there isn't much I can do with everything physically connected the way it is. Unless anyone has any ideas?


I wish I could redo this network a much better way but I feel like both my hands are tied behind my back having only access to the pfsense and the client computers.

 

[ComputerPro]

diagram...

Saw your diagram...
Your just triple NAT'ing is all. Lol, just kidding.
It does look like a bit of a nightmare to me though. I know it sucks to have a device that you can't control also. We have some medical offices in the same boat. The EMR system from the hospital places an ASA at the DR's office that we can't touch. Then when they have some strange issues, its always a coordinated effort between the hospital IT dept and us. We even know them all by name now lol.

Looks like there are some high level network guys who posted replies though, so hopefully things will get figured out.

 

[teksquad]

However traffic on the network when browsing the web is using the WAN B2 address sometimes instead of the WAN address. Why? I'm guessing my 1:1 nat rule, saying all traffic from the clients/server etc must be coming to the pfsense looking like 192.168.168.1 sooo there isn't much I can do with everything physically connected the way it is. Unless anyone has any ideas?

Can you adjust your nat rule based on a source and destination address pair? IE if its coming from this address, destined to this address, then nat to this and use this gateway? Then create another rule for say web traffic that only load balances between WANA and WANB? This way vpn will always use WANB2 and normal web traffic will use WANA and WANB.I think your normal non vpn web traffic is using WANB2 sometimes because that traffic matches said nat rule.