Renumber your internal LAN then. Using 192.168.0.0/24, 192.168.1.0/24 or anything starting with 10. is just asking for collisions like this to happen.

Hmm.  Did you need/want the extra circuit or did you just want more IPs?  If you don't need another circuit they could just route a /29 to you and you could use all the IPs.  Or assign it to another interface and use 5 of them. Just so you know, they assign a /29 giving 6 IPs to use.  This lets them use 3 for HSRP/VRRP/CARP and gives you three to do the same. Create two VLANs on the switch.  We'll say VLAN 28 (for the /28) and VLAN 29 (for the /29). Create a switchport for VLAN 29 untagged.  Plug the new /29 circuit into it. Create a switchport untagged 28 and leave it empty.  This is where you will move the old circuit when you're ready to swing traffic to the VLAN. Create a switchport tagged with 28 and 29.  Leave it empty.  This is where you will move the pfSense WAN when you're ready to swing traffic to the VLANs. Create two VLANs on the WAN interface  (em0, re1, whatever it is) on pfSense: 28 & 29. We'll leave the existing circuit alone for now.  It should continue to function. Create a new interface OPTX.  assign it to "VLAN 29 on WAN interface" Edit the interface.  Rename it if desired.  Set the IP address to 185.64.95.12 netmask 29. Create a gateway for address (presumably - they should have told you what address to use as the gateway) 185.64.95.9.  Do not set it as the default gateway. Hopefully none of that freaks pfSense out.  It shouldn't but I've had pretty squirrelley things happen when you start mucking around with interfaces.  But it's been pretty good since 2.1.0 I think. Now it's time to get disruptive.  Log into pfsense from the LAN. Assign your existing WAN interface to "VLAN 28 on WAN interface" and apply.  This will stop all traffic. Move the old datacenter circuit to the UNTAGGED VLAN 28 port Move pfSense WAN to the port with TAGGED VLANs 28 and 29. And you should be done. You can then create VIPs for .13 and .14 on the new WAN interface. You can do things like simply change the VLAN on the old circuit to 28 instead of patching to a new port.  You could also change the switchport connected to pfSense from untagged 1 to tagged 28 + 29 instead of moving the patch.  I'd do that kind of work from a serial console when mucking around with WAN unless you know you have a good management VLAN to get at it with.

It's only for period of 3 weeks, then our Check Point cluster will move location to where the pfSense is spinning today. I have made the fw rule with sloppy state now and it seems to be working, at least right now - so that might be the solution for the next 3 weeks, thanks a bunch! :)

It really does look like 10.0.0.20 thinks that 10.0.1.11 is in the same subnet - those ARP requests are issued every second trying to find the MAC address of 10.0.1.11 Usually this sort of thing is a wrong netmask on the client or a firewall on the client that accepts ping on the local subnet but does not accept ping from outside the subnet (Windows will do that without being asked). Turn off any firewall on 10.0.0.20 Stare really hard at ipconfig/all (Windows) or ifconfig (*nix) and see what odd network setting it has got from somewhere.

You're not all having the same issue, you have the same symptom. Virtually always, gateway failures are because of connectivity issues on that WAN. Start your own thread with info on what your setup is like, what Status>Gateways looks like, what your system and gateway logs show.

OpenVPN "route" commands add entries to the system routing table telling pfSense to route traffic to OpenVPN.  Openvpn "iroute" commands tell the OpenVPN process, internally, which tunnel to send given traffic.  I have never used the system routing table to make changes to what traffic is interesting to OpenVPN.

Well if you're going to use it for torrent then this is your lucky day.

First, if you really are on 1.1 then it is time to upgrade. I have no idea what features were not in 1.1, but I do know that loads of bug and security fixes have come along since then. What you describe should work on a current version (like 2.1.5 or 2.2 coming). But if you have policy-routing rules on LAN that direct traffic to gateways/gateway groups then that can be directing traffic directly out some other gateway, not hitting the routing table. Put a pass rule at the top of LAN to pass source LANnet, destination 10.0.113.0/27, gateway none - that will ensure that that traffic falls through to the routing table and uses the static route.

Ok thanks, I will wait the 2.2 release :)

I set the WAN interface on pfSense to a static IP address in 192.168.1.0/24 range. I removed the second interface on my Kali machine, so now it just has one interface with the internal network. ..and everything seems to work. Thanks everyone for your help. I'm still a bit confused by all of this, but I'm also relieved :)

No answer at all. Need help, Please!

Well if your modem is bridged, what IP would you be trying to ping.  If you modem is online, does your pfsense get its public IP?  Do you mean you can not ping your isp gateway? So I have a cable modem, which if actually a cable modem would always be in "bridged" mode and only IP on the modem would be 192.168.100.1 ?  is this the IP your trying to ping.  What actual cable modem do you have.  I have the SB6120 for example, its gui interface IP is that 192.168.100.1, and I can ping it from pfsense - even though pfsense has no vip in that network, etc.  You could have a issue if your overlapping the modems IP with one of your lan networks. So you can see pfsense showing its public IP, and I can ping the modem 100.1 address and the isp gateway on the 24.13.x.x address you can find that IP of your isp gateway with a netstat -rn command [2.1.5-RELEASE][root@pfsense.local.lan]/root(10): netstat -rn Routing tables Internet: Destination        Gateway            Flags    Refs      Use  Netif Expire default            24.13.x.x        UGS        0  686822 vmx3f0 [image: pingmodempfsense.png] [image: pingmodempfsense.png_thumb]

@nonayabusiness: Thanks for the response. I thought VLANS might be the ticket. But was hoping to have only 1 SSID. You can do it with 1 SSID but you have to use dynamic VLANs in the AP with some way to tell the AP what VLAN to put what user on.  Overkill for most home networks. So different VLANS == Different SSIDs. I will give that a try. But will probably be the weekend before I get a chance. I've got a few questions (or a lot) After thinking about it I might make a few minor changes to the setup by keeping LAN1 dedicated to 1 computer so the Lockout Rules don't accidently get over written, and setup the VLANS on Opt1. Sound reasonable or over paranoid? It makes sense to do your VLAN config from another interface while you're getting everything working.  If you want to keep that interface normal, untagged just in case, that might be valuable.  Same thing applies to having an untagged port on the switch's management VLAN while you tag/untag ports so don't lose contact with the switch. Will the DLink Dumb Switch cause any issues with pf/Unmanged(dlink)/DDWRT or would it be better to have the AP direct connect to the router (pf/ddwrt)? You're probably going to want to get a managed switch if you want to start tagging VLANs around.  An unmanaged switch might or might not pass VLAN tags.  But you certainly will not be able to put, say, switchport 2 on VLAN 10 and switchport 3 on VLAN 11. Doesn't have to break the bank: http://www.amazon.com/D-Link-EasySmart-Gigabit-Ethernet-DGS-1100-08/dp/B008ABLU2I I'm kind of new with the VLANS, so bear with me. So something like LAN1 interface (sk1) IPV4 10.10.10.1 (to dedicated PC for anti-lockout) OPT1 interface (sk2) HOME interface (sk2_vlan10) Tag 10 IPv4 10.0.0.1 GUEST interface (sk2_vlan11) Tag 11 IPv4 172.16.0.1 WORK interface (sk2_vlan12) Tag 12 IPv4 192.168.1.1 What would the proper Firewall rules look like for the VLANS? Depends on what traffic you want to pass.  VLAN interfaces look just like physical interfaces to the firewall rules in pfSense, so duplicating the default rules on LAN tailored for the interface would be a good place to start. I know this isn't a DDWRT Forum, but I'm sure DDWRT/OpenWRT are the preferred firmware on the embedded devices not capable of pfsense, for things like AP's. So here is a bit more information. I updated the firmware on the AP to DD-WRT v24-sp2 (11/20/14) std - build 25408 I noticed an option for VLANS, which I created one Setup > Networking > VLAN Tagging VLAN0 (None Changeable, If I create more second=VLAN1, third=VLAN2, fourth=VLAN3, I'm guessing this number doesn't effect anything) Interface: ath0/ath0.1/ath0.2/ath0.3/br0/eth0/eth1 Tag Number: (Guessing that would be 10/11/12, depending on the network selected)    Prio: 0/1/2/3/4/5/6/7 I would also create new Virtual Interfaces for the Home (ath0.1) Guest (ath0.2), Work (ath0.3) Does this sound correct? What would my PRIO setting be? I'd just leave prio at whatever the default is.  Get everything working before you worry about QoS/Traffic Shaping. Also If I added a second AP (N-only) I assume I would need to do the same on it but use VLAN 13/14/15? If you want separate LANs, yes.  But if you put the same SSID with the same password on the same VLAN on two different APs, your clients will "roam" between them based on which is better at the time.  Some clients are better at "letting go" of the connection they have and changing to a better one.  At any rate, you would just put the SSIDs tagged to the same VLANs on the second AP.

thats true…

@mcit: I also have an allow all sources to the site to site interface rule here on both which I did not remove. I am not sure if this is required for site to site communication, but I image I would lose access to manage the wireless units if I deleted this. You need rules that match any traffic you want to allow INTO any interface. For traffic originating on Site A's LAN to SITE B's LAN, those interfaces are: SITE A LAN SITE B 5GHz For traffic originating on SITE B's LAN to SITE A's LAN, those interfaces are: SITE B LAN SITE A 5GHz If you want to be able to manage your radios from SITE A LAN, you would need a rule that passes, at least, traffic from 10.20.3.0/24 to 10.20.5.0/24 on SITE A LAN.  You probably want to keep similar rules on both LAN interfaces.

@Derelict: But OP wasn't doing any policy routing to specific gateways so the LAN net to WAN net rule would be unnecessary. You are right - I was looking at tim.mcmanus screenshot and never went back again to look at the OPs original screenshots. So my explanation is relevant to why Tim's rules work - but we do not really know what was the real reason the OPs setup was not working and why it is now.

I am having the same issue.  I didn't think that my modems were garbage though.  I thought they were pretty good modems?  I bought 2 Motorola SB6121 modems as they received good reviews.  It is also a recommended modem by my cable provider(Time Warner, Schenectady NY).  There doesn't seem to be anything to configure with these modems from the IP http://192.168.100.1/….  seems to just give some status and the ability to reboot.  I am just curious what anyone would need to configure in a cable modem.  I thought the configuration was all done on the providers end...

Just to follow up I figured it out. Because we are also using a transparent proxy and that uses the default gateway, the IP reported would always be that of the default gateway regardless of the firewall rules.

@barbosa.rodolfo: I don't think so. I had never heard about policy routing before. What is policy routing Policy routing in pfSense refers to the capability of routing traffic by matching it to specific firewall rules. Each firewall rule allows selection of a gateway. If none is selected, traffic goes out the default gatway or follows the routing table. If additional WAN interfaces (OPT WAN) or gateway groups are defined, these may be selected in the Gateway field when adding or editing rules to direct matching traffic as desired. This is primary used for multi-WAN, though it has other uses as well. https://doc.pfsense.org/index.php/What_is_policy_routing https://doc.pfsense.org/index.php/Bypassing_Policy_Routing