Port-forwarding LAN:X to LAN:Y



  • pfsense: The Definitive Guide notes on page 134:

    The system you are directing this traffic to must reside on a different interface of the firewall.  Otherwise its own network traffic will be redirected back to itself.  In the case of an HTTP proxy server with a redirection port forward on LAN, its own requests will never be able to leave the network unless the server resides on an OPT interface.

    If the port to be forwarded is different than the destination port of the "Port Forward", the traffic will not be redirected back to itself - it will go to another machine.

    Why does this not work, or … what can I do to get it to work?

    Specifically, I would like to forward LAN port 80 to a LAN-IP:8080 running the safesquid proxy server with content keyword filtering.  safesquid will then forward requests to squid as an upstream proxy on port 3128, which will forward the requests to the WAN.  This would achieve transparent proxying through safesquid.

    Superficially, not understanding the workings of PF, it seems like it should be able to forward to any IP:Port other than the IP:Port forwarded.

    Can anyone help me to understand (Always a good thing) and find a way to do this?

    Thank you


  • Rebel Alliance Developer Netgate

    You seem to have missed the point. You say:

    I would like to forward LAN port 80 to a LAN-IP:8080

    But in the text you quoted it says right there:

    The system you are directing this traffic to must reside on a different interface of the firewall.

    So you can't forward from LAN back to LAN. You'd need to put your proxy into a new interface, e.g. on a DMZ subnet, and then forward the traffic there.



  • Thank you, but I did not miss the point, I was hoping that the prohibition was the obvious "Don't forward to the same port on the same interface", e.g. LAN Port 80 to 192.168.0.10:80 where 192.168.0.10 is on the LAN net.  I was hoping that it could be made to work if you were forwarding to a different port.  Logically I don't see a reason why the firewall could not recognize a packet coming in one port and send it to any random address and port other than the one it originally came in, even on the same interface it came in on.  I guess it does not work that way.  Another sentence or two in the book would be good (for me anyway).

    Is there a way / how can I implement a transparent proxy running on a machine out on the LAN, where I also have users needing to use the proxy out on the LAN?

    I already have 4 interfaces and don't want to add another (indeed I would have to look to see if I have another PCI slot)
    (WAN, LAN (For UN*X machines), YEL (For Windows machines w/ up to date AV), and ORA (For untrusted scum).

    Thanks.


  • Rebel Alliance Developer Netgate

    As stated previously (and in the book) you can't port forward back out the same interface that the packet came in. Even if you enable NAT reflection, it just won't work.

    The proxy itself may use 3128 for its port but the proxy itself will still use port 80 when accessing the Internet and get reflected back at itself. You need a separate interface to make this work.

    You can either hardcode the proxy settings on the clients, or use one of the other interfaces.

    If you have managed switches that support it, you could use VLANs instead of more physical interfaces.



  • You are still leaving me hope… the proxy does not go to 80, it goes to the upstream squid proxy in pfsense:

    Safesquid is a proxy very very much like squid in how it functions.

    LAN_Client sends to LAN_Addr:80 (PFSense LAN interface) addressed to Wan_Addr:80
    PFSense forwards to LAN_safesquid-box:8080
    SafeSquid sends request to LAN_PFSense-squid:3138
    PFSense squid sents request to WAN_Addr:80

    Only went into the LAN interface on port 80 once.  The rest of the time used other ports.

    ...Or are you saying that traffic that originates internal to PFSense gets forwarded also?  I understood the forwarding to only be for packets that came in the indicated interface (In this case LAN).  Isn't that what the "Interface" parameter on the Forward setup dialog is?


  • Rebel Alliance Developer Netgate

    You might be able to make that work, but I don't think I'd trust it.

    If you want to try, setup a port forward for tcp/80 on LAN (or WAN, if that doesn't work) with the external address set to "any" and the internal IP of your safesquid box, then turn on NAT reflection.



  • I already had the port forward enabled.  I added the NAT reflection, but it did not work.  Not sure while a port forward for WAN would help, but I would not want to do that anyway, serving the world!  Thanks for trying.



  • New idea on how to get another "apparent" interface so that I can achieve my desired forwarding.  I have been reading about VLANs.  I am really extrapolating here so please bear with me if I am way off base.

    If I created VLANs on my LAN, would I be able to forward LAN:80 to VLAN:8080, having VLAN:80 open to go to the internet?  If so, I have some other questions too.

    When a machine does a DHCP request, it knows nothing of VLANs, so I assume that the request is picked up by the DHCP server and that the DHCP server assigns it an IP and associates it with a VLAN.  How does it choose?  The only differentiator would be the MAC address, so this would have to be manually configured, analogous to a static IP.  Am I on the right track?  I suppose there could be more boxes appearing under the DHCP Server configuration that appear after I make the VLANs, but I don't want to mess up my working configuration until I know that I am barking up a valid tree.

    There seems to be an assumption of a managed switch to route VLANS.  From what I have read, I don't see anything preventing a cheap layer 2 switch from routing based on MAC address, as long as I cut down the MTU by 4 bytes to make room for the VLAN stuff.  1500 bytes is hardly a power of two anyway, so I would expect the impact on throughput due to fragmenting and assembling 1496 vs. 1500 byte packets would be minimal.  Is this good reasoning?

    Do I have to have all other traffic on the physical LAN interface be on VLANs too, or can the "base" lan be "normal", with VLANs running on top?

    Thanks.


Log in to reply