@mjrage:

Bottom line I guess is this: Is PfSense more for users behind the appliance or can it be used for the front side too?

You are looking at the wrong picture.
If a host requests something from your web server it expects the reply from the IP it sent the packet to.
If your server would answer on your other connection it wouldn't be in reply to the request and a firewall in front of the requesting host would simply drop that packet.

Bonding WANs to load balance incoming connections isn't that easy and independent of your router software.

How would you want t to at that to have "multiple monitor IPs for a single gateway"?
Because the last time i checked it was only possible to have one monitor IP for one gateway.

(Of course you can have the same gateway multiple time, but then it's not "the same gateway" even if it is the same IP ;) )

If you're worried about monitor IPs being down.
Just take another IP as monitor.

yes.

In the cisco world I just do a static route for the VPN subnet and let the default route take the rest of the traffic out the WAN1 connection.

On pfSense it's the same.
If you create a static route for a VPN, traffic with the destination of the static route will go to the gateway you specified in the static route.
All other traffic will go to the default gateway.

Just leave the default firewallrule with as gateway * (default = pfSenses routing table).

I'm not sure if it's really possible I would have to try such a setup, but generally with a little hack it should be possible IMO.

Two links is no problem, as long as you dont want the pfSense to failover the VPNs.
If you really need failover, you should be able to get it going with the failover function of OpenVPN itself.

Generally you cannot select in a policy routing rule another gateway than the gateways present in the routingtable, what you configured on the interface config pages and the failover/loadbalancing pools.
So you can create a dummy-failover/loadbalancing pool and use this one in the rule and then modify it.

@http://forum.pfsense.org/index.php/topic:

1: Create a balancing pool and add a dummy-entry.
2: Download the config.xml and find the part with the info you add.
3: Copy/Paste your dummy entry and fill in the real gateway/monitor IPs.

As monitoring IP use one of the immediate hops on your ISP's side.
You cannot have the same monitoring IP for different WANs.

4: Restore the config.xml.

Now your manually added infos should show up.

In this example fill in as gateway the other side of the OpenVPN tunnel, and as monitor IP an IP on the other side of the network.

Disclaimer:
I'm not entirely sure this works and i would have to try it out, but i think it should work.

download with Download manager can also takes advantage, especially server with pararel download allowed

Spent 3 hours searching. Obviously the wrong terms.

Enabling NAT Reflection seems to have done the trick so far!

Cheers

Something else i just noticed (mostly cosmetic).
Port 26 has as PVID 2 (untagged traffic comming in on this interface will be assigned to VLAN2).
At the same time it's marked as tagged VLAN2.
This means tagged VLAN2 traffic is expected, but it will allow untagged traffic as well.

It would be better if port 26 would have its own VLAN for untagged traffic.
After all you only want tagged communication with the pfSense only.
Mixing untagged and tagged traffic on the same interface can lead to unexpected behaviour.
(clients could in certain cases find each other directly via ARP even if they should communicate over the pfSense)

Bump, And…

So I did some further testing, trying to narrow down where the issue existed, and in the process I think I may have found a couple defects...

The first issue is with the original problem in that I have not been able to get any traffic to route from VLAN214 - VLAN220 interface/networks to the WAN connection, given the configuration provided in my OP.

During my testing, I tried the following scenarios:

Scenario #1: Reduce # of VLAN interfaces from 8 to 3; (theory: pfSense cannot route traffic for >4 LAN interfaces)

Configuration: Same as what was documented in the OP, however I removed VLAN's #211, 212, 213. (reconfigured from factory default to maintain consistency in configuration comparison; VLAN214 = opt1, VLAN215 = opt2, etc..)

Result: Negative; issue still exists. I cannot ping the WAN GW from VLAN 214, 215, 216, etc. (though can still ping LAN GW, i.e. 10.0.215.10 -> 10.0.215.254).

Conclusion: The issue is NOT related to the number of interfaces which pfSense can route traffic for.

Scenario #2: Change the VLAN Tag of a working interface; (theory: pfSense has an issue with vlan tag ID's => 214; secondary theory: pfSense has an issue routing traffic from a /24 subnet that is => 214)

Configuration: Using configuration from OP as a starting point, I changed the VLAN tag ID of opt1 (VLAN211) to 214 keeping the original 211 wan IP address in the NAT/VIP config (wan.xxx.xxx.211). Removed original VLAN214 interface/configuration,VIP/NAT/FW rules to avoid conflicts.

Result: Positive; traffic can route OK.

Conclusion: pfSense has no issue with VLAN Tags => 214 or subnets equal or greater to the same number.

Scenario #3: Change the WAN VIP address of a working NAT config (VLAN211->wan.xxx.xxx.211) to one having an issue (VLAN211->wan.xxx.xxx.214); (theory: pfSense has an issue either with VIP's => 4 instances AND/OR VIP's => 214 (as in /32 address number))

Configuration: Using configuration from OP as a starting point, I changed the VIP/NAT config of opt1 (VLAN211) to use wan.xxx.xxx.214, and changed the VIP/NAT config of opt4 (VLAN214) to use wan.xxx.xxx.211.

Result: VLAN211 (using WAN IP 214) failed to route; VLAN215 is able to successfully route.

Conclusion: pfSense is having an issue routing NAT traffic to VIP WAN IP's =>214.

So.. Not sure where to go from here; unfortunately, I cannot get another /28 block of IP's from my ISP at this time that is below the hypothetical threshold/limitation I'm running into. In the interim this is figured out, I've had to scratch my VIP/NAT config entirely and have all 8 VLAN interfaces NAT to a single WAN IP (wan.xxx.xxx.210). Not ideal for the configuration I was hoping, but it works.

Is there anyone out there that would be willing to try and duplicate this issue? I'd like to confirm my sanity…

The second issue I found while I was testing is a rather nasty bug; I'll post it in another thread to avoid hijacking the purpose of identifying a solution to the original problem. (update: here's the other thread: http://forum.pfsense.org/index.php/topic,14940.0.html)

I understood the association between VLANs and interfaces

but in our configuration we've got a multi-services controller (WLAN switch "colubris") which associates VLAN with community ( SSID, VLAN, RADIUS' attributes, DCHP relay, gateway)

Does PFsense manage this kind of "community"?

if you want to, I can send you a screenshot concerning a configuration of a community

Hi ktims,

Wondering if you ever found out the cause (or a solution) for this problem? We just had this happen here and I'm having trouble explaining the cause. WAN went down, and outbound started flowing to OPT1 as it should have. Inbound connections to the failover connection were getting lost entirely though. I couldn't even see the web GUI remotely on OPT1. As soon as WAN came back up, I could see the web GUI via OPT1. Odd… I'd be appreciative of any suggestions!

Thanks,
AR

http://forum.pfsense.org/index.php/topic,9422.msg53290.html#msg53290

Perry…After testing the line directly, it turns out that the owner of the site is blocking our public IP address. I've emailed the webmaster and so has our cable provider to let them know.

Thanks!!

You can't statefully filter that traffic properly with any stateful firewall, weird things will happen because the firewall can't see the entire conversation as it's asymmetrically routed.

You may have sorted this out by now but I had the same issue where I have my ADSL 2+ router in a bridge so that I can assign my internet-facing static IP's directly to the WAN interface on PFsense..

The problem was that I wanted a secure way to manage/reboot the router should there be an issue and at one point there were many…

I ended up enabling another interface on the pfsense machine but the catch is that if you plug the new interface into the router as well as the WAN interface, PFSENSE sees the same MAC address on two interfaces and obviously confuses the routing.

What I did was to enable a two interface VM image that was presented with two unused pysical NICS. I patched the new interface on the physical PFSENSE firewall into the LAN interface of the virtual one and then the WAN interface from the VM went into the router...

Long winded I know...but all I then had to do was use a AoN from my LAN network that translated via my WAN2 interface (the new one on the physical PF) and dump a static route on the physical PF to direct 10.0.0.0 traffic to the LAN interface of the VM PF from where it would be routed to the router...

I needed it to work and I was having straight routing issues which was preventing one LAN interface from talking to another...don't ask me why...still haven't resolved it so the AoN NAT translation was the only thing that allowed this to work properly.

Situation is the same in m0n0wall.

You can try 2.0, it may work perfectly fine for what you're doing.