Issues w/ PIX 501 behind pfSense 2.0
-
I'm running pfSense 2.0-RC1 (i386) built on Mon Mar 28 16:37:49 EDT 2011 on an Atom box with dual Intel gig NICs. I have a PIX 501 running behind the pfSense box the initiates an IPSec VPN back to my office. Off the PIX I have a Cisco phone that registers with my Cisco CallManager server at work. When I power up the PIX, it connects just fine to my ASA5510 at work. The phone registers with the CallMan and it works fine. I plug in my laptop to the PIX, and it also works fine. I'm able to ping the internet and servers over the VPN. After a few minutes, the laptop loses connection to the internet and VPN. However, the phone continues to work fine. It can make and receive calls. Eventually, the phone loses connection to the CallMan and attempts to register back to the CallMan but never succeeds. If I reboot the PIX, it works again, and then the process repeats itself. This PIX worked perfectly when I was using DD-WRT. The only change in the environment has been my switch to pfSense. I know I could probably configure an IPSec VPN connection using the built in IPSec client on the pfS box, but I'd like to know why this isn't working before I go to that step.
Just to give you an idea of my environment, it's the pfSense box hooked to an HP ProCurve 1800-24 Gig switch. There are two VLANs setup on the switch. VLAN1 is attached to the pf box, and VLAN2 is completely separate and doesn't share any interfaces with VLAN1.
When I first started this, I didn't have any port forwards in place or static DHCP. I have added static DHCP (10.0.0.10) and the following NAT rules with the firewall rules automatically added.
WAN UDP * * WAN address 4500 (IPsec NAT-T) JimPIX 4500 (IPsecN AT-T) Jim's PIX Rule WAN UDP * * WAN address 500 (ISAKMP) JimPIX 500 (ISAKMP) Jim's PIX Rule WAN ESP * * WAN address * JimPIX * Jim's PIX Rule
Is there anything else I should add? What could I possibly be missing? Is it foolish to attempt to get the PIX working behind the pf box? Thanks for your help!
Jim
-
OK, So I might have been lying up there. Apparently, port 1 on the switch was being shared between both VLAN1 and VLAN2. The thing is, the LAN interface (VLAN1) on the pf box is 10.0.0.1. The PIX (10.89.25.1/24 subnet) should be forwarding anything on the 10.0.0.0/16 through the VPN tunnel. So it's possible that the PIX was confused as to where to send 10.0.0.1. As soon as I removed port1 from VLAN2 (PIX VLAN) the phone came right up. But that doesn't seem right as the phone/laptop shouldn't have seen 10.0.0.1 at all as it's a different subnet. We'll see if the phone stays connected over night.
-
OK, I think I have figured out the issue. I had created another VLAN on the pf box as 10.89.25.1, which happens to be the same IP as the PIX. And apparently, I had the switch set to receive both VLANs from the pf box. So now that I removed the VLAN2 (10.89.25.1) from switchport 1, the phone managed to stay up all night. I'm assuming that change and adding the ports above fixed my issue. It's also possible that I need to turn off the scramble source port. We'll see how long it lasts.
-
OK, so the phone didn't last too long. I'm going to change to manual NAT.