NAT/Port Forward to internal client on different TCP port
-
@lesserbloops said in NAT/Port Forward to internal client on different TCP port:
I want External:3350 to forward to OPT3 -> 10.10.1.1:3389
I want External:3351 to forward to OPT3 -> 10.10.1.2:3389Do the port forwardings with two different rule on WAN.
For the masquerading it's save to add the outbound NAT rule I suggested above.
The access restrictions must be done by firewall rules. -
@lesserbloops said in NAT/Port Forward to internal client on different TCP port:
But these internal subnets get set up frequently without routing
I'm a bit confused to that.. And if this just just rfc1918 to rfc1918 why would you need to setup port forward and different ports. You could do the outbound nat part of it.
But why would your clients not know how to route to this network, is pfsense not their default gateway either?
-
Thank you both for your help!
@viragomann I have simplified the Outbound NAT rule to anything on OPT3 from WAN, no ports specified, and I'm still seeing that it works for a straight-through port publication (3389 -> 3389) but not when translating a port via Port Forwarding rule.
So the rules I'm working with are:
Port Forwarding
PF1: External:3350 to forward to OPT3 -> 10.10.1.1:3389 -> can experiment with this host, works when default route set
PF2: External:3351 to forward to OPT3 -> 10.10.1.2:3389 -> Never works
PF3: External:3389 to forward to OPT3 -> 10.10.1.4:3389 -> works
Outbound NAT (Hybrid)
OB1 (heh): Int OPT3 src Any tcp/* to 10.10.1.0/24 tcp * using Int addressAnd the technique used is for clients on the internal network (seen as WAN by this Pfsense instance) to connect to PFSense WAN IP:3350/3351/3389 to use these hosts.
I'll add some other hosts in other networks to the mix to see if it's reproducible, but from a naive viewpoint, it doesn't look like the OB NAT rule works when PF is translating ports.
@johnpoz that's right, pfsense is (most frequently) not their default gateway, at least not for some key hosts on those networks, which is why the approach we're attempting for them is service publication on distinct ports per host.
-
@lesserbloops if your trying to work through pfsense where devices are not using pfsense as their gateway.
Your go to quite often use an outbound nat as well as the port forward.
Say you have something like this where your clients are pointing to .254 as their gateway.
Sure you could port forward on 1.100 to get to the machine in .2 network.. But how does he know how to get back? So on the .2 network you would also need a source nat, or outbound nat setup so it looks like its coming from pfsense 2.100 address vs the 192.168.1.x address.
then you could do the reverse for .2 devices talking to .1 devices if you so desired. Not any sort of optimal setup there ;) But it would work.
Another solution would be to host route on these devices that need to talk to each other through pfsense. But that might be more work having to touch each device to add routes. Unless you added the routes to pfsense for specific networks via dhcp.
-
@johnpoz Yep, that's basically what I'm trying to do, but it seems like I can't use a port forwarding rule which changes the destination port along with an outbound NAT rule which changes the source IP successfully.
We have previous experience with ISA Server which had a toggle for "source IP visible to client" vs "source IP of ISA Server" for server publishing rules, and are trying to recreate that no-client-touch experience.
I'll do some tracing and testing and report back!
-
@lesserbloops the outbound nat wouldn't have anything to with the change in port port forward..
You can for sure do what your trying to do.. In the morning I will put up an example of doing this for you.. Football is on ;) So just taking a quick look see what going on while break in the game.
I can setup what your doing on a couple of my vlans to test.. If your doing RDP - don't forget it could be using UDP as well, so make sure your outbound nat is doing for both tcp and udp, etc.
-
@lesserbloops ok got around to doing this finally.
So have a box running on my 192.168.2/24 vlan at 192.168.2.220.. I turned off its gateway.. So you can not talk to it from outside its own network.
I then created port forward rule on my pfsense lan interface 192.168.9.253/24 for port 3390 to forward to 192.168.2.220 3389, and you can see the firewall rule allowing it on the lan.
I also created the outbound nat on my 192.168.2/24 network so traffic coming from lan looks like its coming from the pfsense 192.168.2.253 address.
Now I on client on lan (192.168.9.100) I hit 192.168.9.253 on port 3390, and as you can see rdp works just fine. And from the sniff running on the 192.168.2 interface of pfsense you can see my traffic is coming from 192.168.2.253.. But notice also both tcp and udp traffic to 3389.. But all of it looks like its coming from pfsense IP on that network.
-
@johnpoz Thank you! - working on it in my lab tomorrow.
-
@johnpoz And - thank you, thank you - it's working! No idea what I've done differently this time, but starting from scratch, works really well.
So, firstly thank you for illustrating it so clearly, and secondly I'm going to have to work through a few things to see what's what!
Really appreciate your help John, thank you!
-
@lesserbloops no problem, glad you got it sorted.
It for sure is not a "optimal" sort of setup.. While I am not sure on whatever constraints your having to work with.. And sometimes you just need to get something to work, be it not how it should properly be done ;)
If you have the ability I would look to not having to jump through such a hoop..
Is there anyway for example to connect pfsense to your current routers that are being used as gateways for these 2 networks via transit networks so that pfsense could be used for the firewall router joining these 2 networks together. That way users in network A could just rdp directly to the IP of network B, all you would have to do is allow the traffic you want and in what direction in pfsense.
Optimally you wouldn't need the 3rd router at all, and just connect your 2 different routers via a transit so you could correctly route between your 2 network.. In a truly optimal setup those 2 routers would already be pfsense ;)
I find that pictures are sometimes worth 10k words, and sometimes descriptions no matter how elegantly worded can be misinterpreted sometimes due to different use of terms or misunderstanding of how a term is being used.. The term gateway comes up a lot around here for example.. Users try and use that to describe the IP they set on pfsense interface ;) that is not a gateway, that is the interface IP.. Stating you set a gateway means to me you did that you put in a gateway address ;)
Also users tend to say they did X when they really did (X+y^2) * Z + Q, etc heheheh.. So a "picture" makes sure everyone is on the same page ;)
Which for example is why I drew up a quick layout of how I was understanding what you were up against, so was sure we were understanding each other.
