Trying to get the VPN in this Cisco Pix to work w/ pfsense.
-
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 msApparently 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?"
-
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?
-
Is that rule top-of-the-list or is there any other rule which may "catch" traffic before this intended rule?
-
Is that rule top-of-the-list or is there any other rule which may "catch" traffic before this intended rule?
It's top of the list.