NAT Port forward wrong source address
-
That rule does nothing.
It says that any connection going out WAN sourced from 172.16.21.1 to any address with a destination port of 9115 should have its source address translated to the WAN interface address.
That is exactly what the default, automatic NAT would do.
What, exactly, are you trying to accomplish?
-
I'm trying to make any connection from WAN to port 9115 keep the source address of 71.90.XXX.44 (WAN), sorry if I wasn't very clear.
-
What do you mean "any connection from WAN" ???
If you want to forward connections from THE INTERNET into the WAN interface on port tcp/9115 to an inside server you want a port forward, not outbound NAT.
https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
-
I do have the port forward, and that works correctly. The issue is the server does not see the packet as coming from WAN, it sees it as coming from pfSense, and the service running on the server won't work with that.
Here is the exact scenario:
Service B sends packet to WAN IP:9115
Service A gets packet from pfSense IP.Yes, it would be worlds easier if it could do this internally, but the services don't allow this.
EDIT: This thread here has the opposite solution, rewriting the source IP to the firewalls IP. I'm looking to do the opposite.
https://forum.pfsense.org/index.php?topic=45771.0 -
The default is the opposite.
You have to do nothing special to make the real, inside host that is receiving the forwarded connection see the traffic as sourced from the original source address.
That is the default.
Instead of using nebulous terms you might need to post a packet capture or more details about exactly what it is you think you are seeing.
I suppose it is possible some other device is performing some kind of NAT that hasn't been disclosed yet.
Need details of what is happening to the packets at each hop.
-
That's what I figured, but the pcap shows differently. It is attached below. The port of interest is 9115.
The network setup is as follows:
BroadbandModem –> pfSense WAN (71.90.xxx.44) --> LAN (172.16.0.1/16) --> Server (172.16.21.1)
-
Post the rest of your outbound NAT rules.
Is the port forward the only thing you have in play? No HA proxy or anything?
Are you actually testing from the outside or are you testing via NAT reflection from the inside (which will look just like that)??
I say again:
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting -
Attached is the full list of outbounds. If I run an online open port test I do see the source IP from the website, but the nature of the service I'm running requires the packet come back to the same server with my WAN IP.
I don't have any HA proxy or anything. What I'm trying to get around is the NAT reflection, so the source IP is correct for this application.
When I turn off NAT reflection for the NAT forwarding rule, no packets get delivered.
-
How about you provide the following:
I am making a connection from a host with IP address W.W.W.W/W
The default gateway on host W.W.W.W is X.X.X.X
That host is connecting making a connection to Y.Y.Y.Y port Y
That traffic needs to be forwarded to Z.Z.Z.Z port Z
The source address of the traffic when it arrives at Z.Z.Z.Z needs to be Q.Q.Q.Q
-
I am making a connection from a host with IP address 172.16.21.1/(random source port)
The default gateway on host 172.16.21.1 is 172.16.0.1
That host is connecting making a connection to 71.90.208.44 port 9115
That traffic needs to be forwarded to 172.16.21.1 port 9115
The source address of the traffic when it arrives at 172.16.21.1 needs to be 71.90.208.44
-
You are trying to port forward back to yourself?
I do not think what you are attempting to do is possible.
You are already translating both source and destination addresses once using NAT reflection.
If anything you would want an outbound NAT rule on LAN for matching traffic that sets the source address to 71.90.208.44 but that address is not present on that interface so I do not think you can do that.
Maybe switching to NAT+Proxy would help but the same limitation would apply on LAN.
Your use case is pretty far out there.
-
Yeah not getting this at all.. You want to loop back to your OWN device? And you want it to look like you came from the pfsense WAN IP? For what possible reason would you want to do this??
Why would you not just connect to yourself?
-
I just had a chuckle looking at the thread title NAT Port forward wrong source address.
"wrong source address"
-
Why would you not just connect to yourself?
Lets say I have Service A, Service B, and Client X.
Both Service A and Service B need to be accessible from (WAN IP) for Client X to connect.
The only way these services can do this is to communicate via (WAN IP), so they can tell Client X they are there.Yes, this is idiotic. I know. These same services even communicate locally for other operations, but for the client to work, they must run public.@Derelict:
I just had a chuckle looking at the thread title NAT Port forward wrong source address.
"wrong source address"
To the services, it is the wrong source address, and Service A drops the connection from Service B because of this.
-
To any reasonable expectation of traffic flow, it is the correct source address.
-
To any reasonable expectation of traffic flow, it is the correct source address.
You are correct. These services were originally designed to be run without any NAT. I don't have the liberty of doing such a thing.
-
I would try something like this.
I would not expect it to work.
That protocol any in the screen shot should probably be protocol TCP but I don't think that has been specified by you.
 -
"The only way these services can do this is to communicate via (WAN IP), so they can tell Client X they are there."
What? Makes no sense..
If your services require to be on a public - then put them on a public IP.. Do not try to run them behind a NAT..
-
"The only way these services can do this is to communicate via (WAN IP), so they can tell Client X they are there."
What? Makes no sense..
If your services require to be on a public - then put them on a public IP.. Do not try to run them behind a NAT..
If I had a 2nd IP to do this with, I would. Unfortunately my ISP makes it prohibitively expensive to add another IP.
I would try something like this.
I would not expect it to work.
That protocol any in the screen shot should probably be protocol TCP but I don't think that has been specified by you.
As you expected, it does not work.
-
If I had a 2nd IP to do this with, I would. Unfortunately my ISP makes it prohibitively expensive to add another IP.
Sounds like you've got yourself painted into a corner there.
