WebGUI access from multiWAN



  • Hello,

    I have a pfSense setup with 3 WAN interfaces.
    I've setup firewall rules to access the webGUI on all 3 WAN, but I can only access via he one that has it's gateway set as default gateway.
    If I happen to change the default gateway, I can access the webGUI via the one I set the default to.

    Is this a normal behavior ? Shouldn't the webGUI be reachable from all WAN interfaces if firewall rules are setup properly ?

    Regards,
    Ozy.

    Running pfSense 2.3.1-5, with 3 modem routers connected to the WAN interfaces, with NAT rules to redirect the webGUI access.



  • It works fine when you have routers in front of your WANs that give you a public IP. Not sure what's going on with 'NAT rules to redirect the webGUI'. If you have another layer of nat, your problem is there, not pfSense.



  • @deajan:

    Is this a normal behavior ? Shouldn't the webGUI be reachable from all WAN interfaces if firewall rules are setup properly ?

    …/...

    Running pfSense 2.3.1-5, with 3 modem routers connected to the WAN interfaces, with NAT rules to redirect the webGUI access.

    Not trying to answer yet to your question I would first quite strongly challenge your requirement.
    Why would you want to expose WebGUI on WAN interfaces  :o

    The (secure) way you are supposed to do this is to connect through VPN tunnel then access WebGUI from "inside"

    This been said, you should try to enable "sticky connection"  ;) for testing purpose then you will configure VPN tunnel to get rid of such insecure design.

    I realize that I didn't pay attention to this "detail" but as far as I know, there is no mechanism preventing any kind of brute force attack against WebGIU, i.e. script trying to guess admin pwd. Having WebGUI exposed to internet is a great way to test it  ;)



  • Thanks for the answer, but this is my test setup only, and I don't wan't to setup a VPN now as I very often make changes on it, which would probably disconnect me. Also I'm testing bufferbloat etc with 2 VM on LAN that generate a lot of traffic. A VPN would make it hard for me to remote connect once I saturate my broadband lines.

    Sticky connections is already setup.

    As far as I understood, pfSense only serves the webGUI on the WAN line which has the default gateway, am I right ?



  • @deajan:

    As far as I understood, pfSense only serves the webGUI on the WAN line which has the default gateway, am I right ?

    No, I don't think so.

    As per my understanding, web server exposes GUI to all interfaces, LAN or WAN.
    If you face any problem, this is not because of web server behaviour that would expose only something to default GW (which is to me meaningless) but rather networking issue because packets are sent to default gateway, which is totally different.


  • LAYER 8 Netgate

    This works fine when pfSense owns the public IP addresses.

    Anything else is likely dependent on how you have it set up.

    Instead of saying:

    "I have a pfSense setup with 3 WAN interfaces."

    "with 3 modem routers connected to the WAN interfaces, with NAT rules to redirect the webGUI access."

    State (or, preferably, post screenshots of) exactly what you have done. IP addresses, netmasks, gateways, everything.



  • Here's my setup:

    (Modem router 192.168.1.1/24)–---------------------(pfSense WAN 1 192.168.1.254/24)
    (Modem router 192.168.2.1/24)-----------------------(pfSense WAN 2 192.168.2.254/24)
    (Modem router 192.168.3.1/24)-----------------------(pfSense WAN 3 192.168.3.254/24)

    All 3 modems have are the same, and have the webgui and ssh port NATed to 192.168.x.254.
    If I happen to change the default gateway, I can access the webgui (or ssh btw) via the public IP of the WAN I changed the default gateway to, so I'm pretty sure the NATs are done right.

    Screens attached.

    I say it again, this is not a final production setup. I just really wonder what I am missing here.









  • LAYER 8 Netgate

    What is the source network you are connecting from?

    What are the WAN-side addresses of the upstream devices?

    That all looks like it should work if the port forwards in the upstream devices are correct.


Log in to reply