Using a Virtual IP on LAN and redirecting it to a specific server behind pfSense



  • Hello,

    I have a WAN connection (IP x.x.x.x) with a Virtual IP configured on it (y.y.y.y).  It seems to work, as accessing http://something.com, which points correctly to  y.y.y.y, now brings me to the pfSense UI (or tries to, there is a DNSbind warning which is to be expected).

    The second thing I believe I needed to do is redirect everything coming to y.y.y.y (but NOT x.x.x.x) to 192.168.1.10.  So I went ahead and created a NAT entry with the following parameters:

    Interface: WAN
    External subnet IP: y.y.y.y
    Internal IP: 192.168.1.10
    Destination: any
    NAT reflection: system default

    The NAT part isn't working, as my connections still attempt to reach the pfSense UI (specifically I get a DNSbind attack warning, but that just tells me it's attempting to reach the router) instead of whatever is found on 192.168.1.10.

    My tests are done using a browser, as 192.168.1.10 is an HTTP server.
    The page web should come up, or if it was an apache misconfiguration, at the very least the pfSense UI would not come try to up.
    The NAT rule is active.

    What step am I missing? Even if the firewall rules were an issue, I wouldn't end up on the pfSense UI.

    Thanks for any help or pointer to a relevant document.

    Michael



  • Don't test external port forwards from LAN.  Either use an external connection like a VPN or system on the public side, or use your phone's browser to test it.  Trying from LAN gets you into NAT reflection issues which can complicate things and give you problems.

    https://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks



  • Don't test external port forwards from LAN.

    Very good point, but I wasn't. I have a Firewall rule opening up the router's WAN (ina data center) from my own fixed IP (at the office). I am testing from the office, through the WAN (no VPN in this scenario, although one is setup for other purposes).



  • Sorry, it wasn't clear to me that you were testing externally since getting the pfSense GUI is a symptom of doing it from LAN.  A NAT port forward is usually pretty simple, just one port forward rule and one firewall rule on WAN.  Can you please post a screenshot of both just to confirm your settings?  Obscure your public IP on the NAT rule before you post.



  • Sure thing. See attached. 10.06.25 is the actual LAN ip, not 192.168.1.10.

    I am using  2.2.6 BTW with very little configured as of now, as it's just been built, in case is matters.

    The obfuscated part is the Virtual IP on WAN, not the master WAN IP. The "home" alias is just the alias for my fixed IP used to access the pfSense UI remotely for the purpose of this test.






  • First, I wouldn't use 1:1 NAT just to forward a web server.  A port forward of 80 and 443 is usually enough unless you plan to expose more services.

    Second, you don't seem to have a Destination specified in your firewall rule.  It should be the IP address of the resource you're trying to access.


  • LAYER 8 Netgate

    The inside (Post-NAT) IP address.



  • First, I wouldn't use 1:1 NAT just to forward a web server.  A port forward of 80 and 443 is usually enough unless you plan to expose more services.

    Point well taken, this is just me trying to make sure Virtual IPs are working as I want them to, things will be tightened up.

    you don't seem to have a Destination specified in your firewall rule.  It should be the IP address of the resource you're trying to access.

    I thought Internal IP was the ressource I was trying to access. The description for Destination in the pfSense UI is

    "The 1:1 mapping will only be used for connections to or from the specified destination.
    Hint: this is usually 'any'.

    That being said, while it's not quite working now that I put in the internal IP in "Destination", it's not failing in the same way, probably due to firewall rules at this point. Thank you


  • LAYER 8 Netgate

    KOM talking about the destination IP in the firewall rule, not the 1:1 NAT rule.


Log in to reply