@XIII: For site to site only the pfSense devices are aware that a vpn exists, to the clients on each side it is seen as another network through which they go through the pfSense device to access, no additional gateway required. As long as the clients on each side have their local pfSense box set as their gateway it will route just fine. Where is the client? If its at one of your sites, there is nothing you need to do with it. Hi XIII, The clients are spread out across the world, working from their homes. Currently they connect to our Microsoft RRAS PPTP/SSTP VPN server.

yes it's possible. http://doc.pfsense.org/index.php/How_can_I_completely_disable_NAT%3F#Disable_NAT

That would absolutely work - thanks!

@nnicanor: I have same problem reported some time ago, i was added rules and static routes not work i also using multilan and multiwan, i have to segment my network but is dificult set rules to let traffics between multilans and not work properly to pass traffic between static routes and lan subnets i using between networks and pfsense 2.0.1  one pfsense 1.2.2 and trafic pass ok, i need to remove 1.2.2 but new version have this issue reported since beta versions. Start your own thread, please don't hijack threads. The underlying PF version in 1.2.2 didn't have as tight of filtering as current versions and it will not pass asymmetrically routed traffic by default which is what I'm sure you're seeing. Start a thread describing your problem for help there.

Quickest way would be to make the change on a local copy at github, and then do a pull request: https://github.com/bsdperimeter/pfsense/commits/master

That's pretty much it. But there might be some problems/work-arounds before getting there

Hi Heper, Thanks for the reply. You hit the nail on the head, I have a gateway group as the default gateway and that is the only rule. I can't work out why it was working before but by explicitly putting in an allow rule without a default gateway before the gw rule it works. I hadn't realised pfsense worked that way! Thanks Graham

-configure the vlans on pfsense + assign interfaces for each vlan  (both can be done at interfaces –> assign) -create the appropriate firewall rules configure your ports on the switch: -tag all vlans on a single port and connect it to pfsense -create the desired untagged ports and don't forget to set the pvid done

@dhatz: Unrelated to the original question, but rather than putting the squid box on the WAN subnet, have you considered putting it on a 3rd ("dmz") subnet? Hi dhatz, Yep - absolutely.  Originally, the squid server was being shared by other firewalls who also use transparent NAT,  and the only location in common was the WAN subnet.  Since then the number of firewalls has been reducing following the transition period so now the best thing is to relocate to a DMZ. There are three main reasons I can think of: Less security concerns over locking down the squid box (when on the WAN subnet it is on a public internet address with no firewall protecting it) Simpler with more fexibility - in the multi-wan environment we are considering,  the 'smarts' to choose different WAN gateways based on failover or load-balancing is built into pfsense.  With the current (external squid) design I have to duplicate wan failover/loadbalancing into the squid host. So moving squid into DMZ I can set up all the  WAN load-balancing/rate-limiting/filtering once in pf and squid can take advantage of it just like any other client on the internal networks. Not really a DMZ response and I know this not what you were suggesting, but I caution people deploying squid on a primary  pfsense firewall in a more 'complex' environment.  Squid on pfsense is great - no problems with me there!  However I am always cautious when a proxy (or load-balance) function is deployed on a firewall.  For example.  My 'guest' dmz is not allowed to connect to anything on the 'inside' network.  But if guests are transparently captured to squid on the firewall, how can I be absolutely sure that squid is not forwarding requests internally on behalf of the guests?  Admittedly, squid has all the configuration options needed to enforce this - and probably pf as well,  however I just feel better knowing that squid is completely separated and has no chance of being mis-configured in this way.    Best to put that role (squid) in the correct network location to start with.  For me at home though - squid goes on the firewall  :) ..and just to tie this back to the thread topic a little,  as I start working with floating rules and more 'generic' PBR for transparent port 80 capturing - then in my mind at least - this introduces more chance of user error (me :) ) such that things could be going to squid that shouldn't  - again,  more reason to ensure squid is correctly located on the network so that squid's role is enforced by the network security architecture, and less dependant on my late night stumbling around on keyboards… GB

The same way you route public IPs with anything. Static routing, OSPF, BGP, or RIP depending on your circumstances and equipment.

That introduces all kinds of complications with traffic routing and return routing. Save yourself a lot of headaches and don't do that. Put each gateway on its own interface and subnet.

Mmmm is the new inteface on your pfSense wired directly to the other subnet? Or does it go through their Drytek router?

running newer versions of pfsense will solve the vlan issue

Resolved by following this manual http://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards Its a dell server with broadcom NICs

Thank you all, I change the Gateway advanced option in the rule and it work as I wish.

@dhatz: @Nachtfalke: In front of all three lines there is a modem/router which is doing NAT - not more - pfsense interface is the exposed host. Although it's probably unrelated to your WAN3 issue, why did you put another router in front of pfsense to handle NAT ? … I had trouble with PPPoE connections/reconnect and because all my three ADSL connections do have the same gateway.