TCP full address transparency
-
[client aa.bb.cc.dd: z]<–->[pfsense[192.168.3.1]]<–-->[src client aa.bb.cc.dd: z, dest:192.168.3.2]
How to achieve it?
Problem: port z required -
What do you mean by "full address transparency"? Normally, addresses are not changed when passing through a router, unless NAT is used. The address you list for pfSense is in a range that's often used for NAT. What is it you're trying to do?
-
You can't avoid the "extra" ports as long as NAT is used. Get a routed subnet from your ISP or use bridging if you must.
-
Your talking about inbound traffic from public IP to your port forward.. And your saying the source port is being changed?
so you want this.
client [publicIP:[b]z] –--- internet ---- [publicIP] pfsense [192.168.3.1] –-- [publicIP:[b]z –-> 192.1683.2] Server..
But your saying your getting this?
client [publicIP:[b]z] –--- internet ---- [publicIP] pfsense [192.168.3.1] –-- [publicIP:[u]Y –-> 192.1683.2] Server..
Or are you talking about traffic from behind pfsense to something outside (wan).
-
Your talking about inbound traffic from public IP to your port forward.. And your saying the source port is being changed?
so you want this.
client [publicIP:[b]z] –--- internet ---- [publicIP] pfsense [192.168.3.1] –-- [publicIP:[b]z –-> 192.1683.2] Server..
But your saying your getting this?
client [publicIP:[b]z] –--- internet ---- [publicIP] pfsense [192.168.3.1] –-- [publicIP:[u]Y –-> 192.1683.2] Server..
Or are you talking about traffic from behind pfsense to something outside (wan).
Yeah you got it,
I am using haproxy, I need IP and port(imp) received at front end, to be forwarded to backend server
haproxy changing port z->y. I need the port receive at front end -
What do you mean by "full address transparency"? Normally, addresses are not changed when passing through a router, unless NAT is used. The address you list for pfSense is in a range that's often used for NAT. What is it you're trying to do?
I want the port receive at front-end to be forwarded to backend
- pfsense running haproxy with nat directing to itself at port 54545
- source 168.122.33.10:8222 to destination hoho.com(whatever 197.116.22.10:54545 as frontend )
- front end spoof source using 168.122.33.10:8222 to backend server 192.168.3.2:4322
now problem is haproxy changing port 8222 to 3432
I need 8222
-
"haproxy changing port z->y. I need the port receive at front end"
Well that is on HA proxy, not pfsense.. Yeah kind of needs to do that to keep the sessions straight
If you don't mind me asking, what are you doing that the source port makes any difference.. Why should it matter.. Its just going to be some random high port…
-
now problem is haproxy changing port 8222 to 3432
I would expect it to do this. What if you had two clients that connected to haproxy, both on ports 12345? Do you expect haproxy to magically share the same port for two connections?
-
HA Proxy makes a new connection to the inside host. It is unavoidable.
-
now problem is haproxy changing port 8222 to 3432
I would expect it to do this. What if you had two clients that connected to haproxy, both on ports 12345? Do you expect haproxy to magically share the same port for two connections?
load balancer will use Client IP and Client port for server side connection
-
now problem is haproxy changing port 8222 to 3432
I would expect it to do this. What if you had two clients that connected to haproxy, both on ports 12345? Do you expect haproxy to magically share the same port for two connections?
load balancer will use Client IP and Client port for server side connection
That sounds like a security nightmare waiting to happen. Do you have all unknown IP addresses getting routed your haproxy? How could you router know which public IPs haproxy is claiming to temporarily own?
I'm afraid to google this topic because it just sounds like a horrible idea.
Never mind, had to look. "Transparent mode requires that the haproxy be the default gateway of the backend servers.". I guess that answers my question.
We just have our reverse proxies add a header to indicate what client it's coming from. I just really really hate the idea of an internal server attempting to communicate with an external public IP over an unsecured channel.
But good luck with getting this to work.
I know the NAT rewrites source ports, not sure if scrub does anything like this.