Yes. The WiFi router will not be acting as a "router", strictly talking. The cable coming from the pfSense needs to be connected on one of the "LAN" ports of the WiFi router, and whatever device you want to connect here also needs to be connected to the LAN ports (you shouldn't use the WAN port on this setup). This is something that a lot of people fail to realize (if you plug the cable from pfSense to the WAN port, you will most likely be creating a double NAT and you might get some issues that will be a pain to troubleshoot). Also, make sure the DHCP server on the Wi-Fi router is turned off. Regards!

You need to create a bridge among the 2 interfaces. Why do you need this? It is usually better and will provide you better performance to just use a simple and cheap switch

You just need to create a NAT port forward on WAN, destination address: the virtual IP, destination port: the outside port (443), redirect target IP: the internal IP of the server, redirect port: the internal port (probably also 443). It should work after that. Outbound NAT rules are not required if you just want this. If you also want that server to identify itself with the other public IP when it goes to the internet, you can create an Outbound NAT on WAN, with source IP: the IP of the server, traslation IP: the virtual IP. But this is not needed if you just want to provide access on the 443 port on the other IP. Regards!

hi podilarius, thanks for your reply. i didn't disable the firewall - but i did add an allow all rule. it turns out the problem i had was i added the IP address of the VLAN interface in the "gateway' field… my thinking must have been that its what the dhcp passes to the client. but it must have meant that the interface itself was pointing to itself . anyway once i set that to none it worked. cheers, m

Ok. Thank you for help!

@Chucko: I find the "default gateway" confusing - if the firewall rules are directing traffic to the gateway group, what traffic uses the "default"? The system will route all traffic for which you haven't explicitely defined a gateway, through the default gateway. Also traffic originating from pfSense itself will use the default gateway unless another one is specified. @Chucko: Oh, so there's a manual configuration step to switch between the gateway groups? I didn't see a way to do the switchover between groups automatically. That makes a little more sense. Changing the gateway group is a manual procedure. It looks that you want to always use WAN1 unless it's down right? Let's suppose that at some point, for some reason you want to always use WAN2 instead, unless it's down. So you grab your rule, and change its gateway to the one which has WAN2 as Tier1. Or if you want to load balance, switch the rule's gateway to a gateway group that has both WANs on the same Tier.

Done! The problem wasn´t on quagga, but on the OSPF damon of a brocade switch core. Thanks!

I wonder there is no update so can this be reported as bug?

@j@svg: One more question, at what point is the gateway admitted back into the group? I'm not 100% sure, but I believe the previously-failed gateway is put back in the group/pool after it comes back up. This entry in the manual may be useful to you. Lastly, mostly unrelated but somewhat relevant, there seems to be a widely-reported bug with 2.1-RELEASE that some users (including myself) experience, where if a WAN interface loses its connection (say, if the cable comes unplugged) when the connection is restored pfSense gets stuck continually rebooting the NIC and will never re-establish the connection, until you power-cycle the whole box. So, if you're on a flaky ISP, you may want to hold off loading 2.1-RELEASE until they've addressed the issue.

Start here  ;) https://doc.pfsense.org/index.php/Main_Page https://doc.pfsense.org/index.php/How_can_I_completely_disable_NAT%3F#Disable_NAT

@doktornotor: Yes, you already identified that you have a problem with missing DNS records, so… the point is? The problem, which we solved with a PM or two, was that he accidentally entered fully qualified host names under the domains tab instead of just the domains. It wasn't a problem with DNS.

You may need to create acls for each lan ip range and associate it with tcp_outgoing_address directive. All in custom options.

I'll give that a try, thanks

After sleeping and getting a fresh perspective on it, I found the issue.  In my virtual IP, I read the subnet comment wrong and thought it was a CIDR range instead of a subnet mask.  Changing it from /32 to /29 fixed the issue.  Everything else I did was correct, with the exception of intentionally leaving out the port forwarding rules. Hopefully someone else sees this and it helps them figure out how to perform a similar setup.

I jsut wanted to let you guys know that the issue is gone. The problem was in the Cisco 2621 after all. I forgot to set the "last resort" on this router, so anything on a network that it was not familiar with, was being dropped and never actually went to the PFsense. Thank you for your help Robin

VRRP is CARP. Well almost. VRRP is the cisco implementation, CARP came a bit later and is the opensource implementation of the same functionality (redundancy). Actually CARP is a bit more since it offers encryption.

I'm too sick and tired to be messing with this. The problem was that the openvpn client was pulling 0.0.0.0/1, added route-nopull and route 0.0.0.0/2 (I know, it's a fugly hack, but it will work for this :) ) If there's a cleaner solution to this, I'd happily change.

Thanks for all. I solved with nat outbound. Many thanks for all.

Many thanks!! It works!! Thanks for all.