Port Forwarding on LAN interface

johnpoz

@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?

AWeidner

@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.

johnpoz

@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.

AWeidner

@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

johnpoz

@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

https://forum.netgate.com/post/868337

AWeidner

@johnpoz
I will have at look at the examples you provided tomorrow. I found a solution, but maybe i can learn something from them.

SteveITS

@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.

AWeidner

@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

https://forum.netgate.com/post/868337

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

AWeidner

@aweidner

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.

AWeidner

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 established

This is not my prefered solution, but after three days i am out of ideas. I am sure there is a more elegant way.