Port Forwarding on LAN interface
-
Setup
- pfSense 2.6.0-release
- LAN-Interface 192.168.1.1/24 (VLAN1)
- Server in a different VLAN, IP 192.168.10.1/24 (VLAN2)
What i want to do
Forward all requests to 192.168.1.1 Port 3389 (RDP) to 192.168.10.1.What works
I can ping the Server at 192.168.10.1, nmap shows open ports, including RDPWhat does not work
Connect to RDP via 192.168.1.1:3389. I can see incoming packets on the server with Wireshark, but no connection is made.The incoming packets on the server still carry the ip address of the client from VLAN1, instead of the firewalls LAN Address.
I guess what i am looking for is masquerading, but i do not how to achieve that.
The Port Forwarding rule looks like this:
Interface Protocol Source Address Source Ports Dest. Address Dest. Ports NAT IP NAT Ports Actions LAN TCP * * LAN address 3389 (MS RDP) 192.168.10.1 3389 (MS RDP)
I am running out of ideas. Any help would be appreciated.
-
@aweidner
Change the protocol to TCP/UDP. RDP likes both. -
@aweidner For starters just curious why would you think/want to create a port forward?
2nd you understand that rdp can use and wants to use UDP as well, not just TCP.
Why would you not just go to 192.168.10.1 from your lan?
I can see incoming packets on the server with Wireshark
Then why would you think the issue is with pfsense?
-
@johnpoz @viragomann
Changing to TCP/UDP did not solve it. The server still receives the packets with the source ip of the client in VLAN1 and not the ip address of the LAN interface.@johnpoz
Hope my reason makes sense: An IPSec tunnel ends on that pfSenses VLAN1. The IPSec client should be enabled to access the server in VLAN2 via RDP. It seemed the easiest for me, to just forward port 3389 from the pfSense to that server, as the pfSense already has access to it.I have no control over the devices on the other side of the IPSec connection.
-
@aweidner said in Port Forwarding on LAN interface:
client in VLAN1 and not the ip address of the LAN interface.
Why would you think a port forward would do that... If you want to get around some firewall rule or restrictions on not allowing other than local networks to rdp to it.
This would be a Outbound nat on your vlan interface so traffic for rdp looks like its coming from the pfsense interface IP.. I have actually gone over this multiple times on how to set this up, which is a simple source nat. Normally used for devices that don't have gateways set, like IP cameras, etc.
-
@johnpoz said in Port Forwarding on LAN interface:
Why would you think a port forward would do that... If you want to get around some firewall rule or restrictions on not allowing other than local networks to rdp to it.
This would be a Outbound nat on your vlan interface so traffic for rdp looks like its coming from the pfsense interface IP.. I have actually gone over this multiple times on how to set this up, which is a simple source nat. Normally used for devices that don't have gateways set, like IP cameras, etc.
Could you point me to your tutorial? I guess i am using the wrong search terms.Nevermind, you pushed me in the right direction or so i think. At least it works now.
In addition to the rule i created previously, i added a Outbound NAT rule
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port LAN any tcp/udp/* * tcp/udp/ 3389 (MS RDP) LAN address * checked
-
@aweidner here is one where I show the outbound nat so it looks like coming from the lan interface
https://forum.netgate.com/post/1001649
Here might be a better example
-
@johnpoz
I will have at look at the examples you provided tomorrow. I found a solution, but maybe i can learn something from them. -
@johnpoz said in Port Forwarding on LAN interface:
rdp can use and wants to use UDP as well, not just TCP
This is an aside to the OP's question, but, while you're not wrong, it will not only work just fine using TCP (the original way, up until a few years ago I think? maybe Win10?), but also in my experience using UDP works fine up until the connection hangs requiring a disconnect/reconnect. Especially so connecting to Windows 10...Windows 11 seemed a bit better but still has occasional issues. When we were first testing to allow UDP with 10, it happened probably once a day. Multiple clients, multiple PCs.
-
@johnpoz said in Port Forwarding on LAN interface:
@aweidner here is one where I show the outbound nat so it looks like coming from the lan interface
https://forum.netgate.com/post/1001649
Here might be a better example
I spoke too soon. The IPSec client cannot use the redirected port. In the states table the connection has the status "CLOSED:SYN_SENT". He can reach port 443 on the LAN interface of the pfSense though as well as getting ICMP replies.
The Firewall Logs show no entry for a blocked connection.
TCPDUMP is not a great help either, it shows nothing on port 3389 on either interfaces including enc0 when the client tries to connect to this port.
That was a typo on my side. It generates output with the correct ip address on enc0 -
Replying to myself: I cloned the rule from my first post and changed the interface to ipsec. Now i am seeing incoming traffic on the RDP server, when the IPsec client tries to connect.
But appearently he does not get any replies and thus cannot connect.For every two rows of connection there is one line of Reset and four rows of Retransmission.
-
Final reply:
I could not find a way to make this work. The IPSec client was not able to make use of the port forwarding and Outbound NAT rules. The replies form the RDP server never reached the IPSec client. Disabling the firewall with pfctl -d did not make this work either, so i suppose it is some kind of system rule that cannot be overridden (i.e. "do not forward port forwarding replies to IPSec interface".My solution:
Port forwarding from the firewall that seperates VLAN1 and VLAN2 to the RDP Server
Outbound NAT rule for RDP with the LAN IP address of the pfSense.
IPSec client connects to the RDP port / IP address of the Firewall that separates the VLANs.
RDP Server sees the pfSense as Origin and replies accordingly
pfSense sends packets back to the client with the IP address of the firewall
Request and reply have the same IP address (of the firewall) -> connection establishedThis is not my prefered solution, but after three days i am out of ideas. I am sure there is a more elegant way.
-
-
-
-