as would be ideal? I have to use vswitch? NAT interface is an alternative? NIC1 - NAT mode - em0 - NIC2 - bridged mode - em1 - IP Static NIC3 - NAT mode - OPT1 - or NIC1 - NAT mode - em0 - NIC2 - bridged mode - em1 - IP Static

Update: Since my last post we have moved to our new location. There are quite a few things that I have learned in the past weeks concerning multi wan, PPPoE and PPPoA, ML-PPP and DSL in general. With Podliarius' information/translation I was able to convince my provider that the setup as proposed would work. Unfortunately, we ran into quite a few snags along the way. We purchased two TD8816 modems, but these we unable to provide the required bridging. RFC1483 is not the same as PPPoA -> PPPoE media conversion. PPPoE only works if the ISP actually has the protocol running somewhere. In the case of our ISP as I understand it, everything is pure ATM until past the DSLAM. Instead, we needed modems that were able to masquerade as PPPoA client in a transparant fashion, while providing a PPPoE server on the router's side. Searching this forum, I came across a post by Stephenw10 referring to a specific modem capable of PPPoA -> PPPoE translation. We purchased two of these modems and pfsense was able to connect to our ISP through them. However, ML-PPP does not seem to be active. We contacted our ISP and they insist that they have explicitly enabled ML-PPP on their end. In the PPP log, I see a lot of chatter, but I am unable to determine if pfSense is even attempting to connect with ML-PPP. ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM c29a637b ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #175 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM c29a637b ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #174 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM c29a637b ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #173 ppp: [wan_link1] LCP: state change Starting --> Req-Sent ppp: [wan_link1] LCP: Up event ppp: [wan_link1] Link: UP event ppp: [wan_link1] PPPoE: connection successful ppp: PPPoE: rec'd ACNAME "Vigor2000 PPPoE" ppp: [wan_link1] PPPoE: Connecting to '' ppp: [wan_link1] Link: reconnection attempt 1630 ppp: [wan_link1] Link: reconnection attempt 1630 in 2 seconds ppp: [wan_link1] LCP: LayerStart ppp: [wan_link1] LCP: state change Stopped --> Starting ppp: [wan_link1] LCP: Down event ppp: [wan_link1] Link: DOWN event ppp: [wan_link1] PPPoE: connection closed ppp: [wan_link1] LCP: LayerFinish ppp: [wan_link1] LCP: state change Req-Sent --> Stopped ppp: [wan_link1] LCP: parameter negotiation failed ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #172 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #171 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #170 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #169 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #168 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #167 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #166 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #165 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #164 ppp: [wan_link1] ENDPOINTDISC [802.1] 00 e0 2b 89 f2 28 ppp: [wan_link1] MP SHORTSEQ ppp: [wan_link1] MP MRRU 2048 ppp: [wan_link1] MAGICNUM 3be9b6e4 ppp: [wan_link1] MRU 1492 ppp: [wan_link1] PROTOCOMP ppp: [wan_link1] LCP: SendConfigReq #163 ppp: [wan_link1] LCP: state change Starting --> Req-Sent ppp: [wan_link1] LCP: Up event ppp: [wan_link1] Link: UP event ppp: [wan_link1] PPPoE: connection successful ppp: PPPoE: rec'd ACNAME "Vigor2000 PPPoE" ppp: [wan_link1] PPPoE: Connecting to '' ppp: [wan_link1] Link: reconnection attempt 1629 ppp: [wan_link1] Link: reconnection attempt 1629 in 4 seconds ppp: [wan_link1] LCP: LayerStart ppp: [wan_link1] LCP: state change Stopped --> Starting Regardless of ML-PPP, both DSL connections work and I can choose which IP I want to use on WAN by using the login data for either DSL connection. So, we are three quarters of the way there. Can someone help me figure out if there is something wrong on my end or if there is something my ISP needs to set up?

NP. Just starting with the basics. I would ditch the 1:1 rule for now. That is not doing what you think it is. The AON (automatic outbound NAT) is mapping it to only 1 IP address, the WAN address. Looks like you will need to port forward anything else internally.

I meant 443 is going out through failover gateway group by policy routing rule.

This is possible with 1:1 NATing. I have a /29 range of IP addresses but they're static.  If you're going to get the same range of 5 public IP addresses from your ISP you should be fine.  If not there's no practical way to re-map a new address range to the routes you've already established.

Why is your WebFileServices on a different /29 network when the other IPs are on a /32 subnet? Also, if you're trying to access an internal device from your internal network using that device's external IP address, there's a good chance it's going to return the pfSense login page, or in your case the dashboard since you're already logged in.  You need to test it from a WAN connection that is not part of your pfSense installation.

This was the problem! DLink Router can't route LAN IP's from the WAN side, to the LAN side! How to solve? -> connect the LAN from pfsense to a LAN of the router! Don't use WAN side anymore and DEACTIVATE (!!) DHCP and UPnP on router! Thats it!

Hi, mrbnet! Sorry I was wrong. Despite the OSPF routes already there, you have to put 'iroute' statement with net behind client's gateway in 'Client specific overrides - Advanced' on the server side for each client. It seems to be double work, but this is how OpenVPN works in 'Peer to Peer ( SSL/TLS)' mode. I myself use OSPF for failover only and do not need to expose my home net to main office, so I do SNAT at home and 'Remote Access ( SSL/TLS + User Auth)' . Somehow it works without 'iroute' at the server side/

As set - 80 would be warning (not down) and 100 would be down

It would take some serious funding to speed up, but otherwise it'll be a couple years I'd say. We are looking into using kickstarter to fund larger features like that, but we're still working on the details.

Impossible to say without more info. The system log when the interface is plugged in might help. Also if you're on 2.0.x, you might give a 2.1 snapshot a try. It could also be a problem with the NIC, the cable, or the modem on that line.

I had temporary needed this, too… add an IP alias from new network for each firewall and the rest of IPs can be used again as CARP adresses within this network.

Ok, so I've done some "re-modeling" on my configuration and been able to set up the OpenVPN as WAN and the LAN as my physical interface making the physical interface into the gateway for the OpenVPN and it seems to work without any issues, now I'm just trying to setup a proxy from my LAN (physical) to WAN (OpenVPN) with login but can't really figure out squid. I think I need to use iptables to setup routing not sure how to work this with squid, still trying to solve this but any help would be great :)

I use it at my office and home (which is severely limited on bandwidth) and it works very well. If the WAN3 connection is that bad, change it out for a different DSL provider or something (maybe cable). Either way works.

I am running a similar setup with a dedicated server. You can save one of the IP addresses if you assign a private address (ex. 192.168.1.10) to the VMkernel - Management interface. It is also more secure, even if you can configure access list and lock-down the ESXi host I reckon this is a better approach. Setup pfSense WAN to X.X.X.91 and use Virtual IP's and NAT 1:1 for the rest. To manage the ESXi host I use a IPsec tunnel from a different DC but you could probably change the vSphere Client port (see http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021199) and then do some port-forwarding to 192.168.1.10? Hope this helps.

That is true, but, you can use manual outbound nat to remove the rules auto created for the one that does not need NAT. It would just route those connections since they are internet route-able. The other interface would NAT since there are rules to do so.

Your direct ISP connection should be configured as a separate WAN interface. It will automatically create an entry in System > Routing > Gateways. For your WiFi failover you need to configure your 2nd NIC connected to the access point as another LAN interface and set it to DHCP. This should add an additional gateway under System > Routing > Gateways. The create a gateway group with the LAN gateway in a lower tier for failover and set the group as the default gateway.