Port forwarding from external IP to another external IP
-
"It works when I go direct."
Which is what you should be doing.. Here is where you have a problem..
Your client is talking to 1.1.1.1 that is where he sent data.. 1.1.1.1 sends this data on to 2.2.2.2 but 2.2.2.2 is going to directly answer the sender.. lets call that 3.3.3.3… Why would 3.3.3.3 accept the answer from 2.2.2.2 when he sent data to 1.1.1.1
For your thing to work you would have to not just forward the traffic, you would need to source nat it so that 2.2.2.2 sends data back to 1.1.1.1 which sends it back to 3.3.3.3
In a typical port forward 3.3.3.3 sends to 1.1.1.1 which sends it on to 192.168.1.100, 192.168.1.100 talks back to 3.3.3.3 via 1.1.1.1 so to 3.3.3.3 he is only talking to 1.1.1.1
For your thing to work all traffic would have to go through 1.1.1.1 even the answer from 2.2.2.2
It makes no sense to do what your doing.
If you want users to be redirect to 2.2.2.2 when taking to 1.1.1.1 have 1.1.1.1 on port 80 send them a 301 or 302 in the http request, this tells them hey this site is moved - go talk to the fqdn of what 2.2.2.2 is listening on. 3.3.3.3 would then directly talk to 2.2.2.2
-
You could maybe do that using OpenVPN with pfSense on both sides. But as far as a hairpin port forward, no.
-
You could maybe do that using OpenVPN with pfSense on both sides. But as far as a hairpin port forward, no.
I've never seen it done with openvpn, I would definitely enjoy an example, could you PM me the example or post it here if its not too off topic?
As far as hairpinning, you can absolutely do it. I used to hairpin my VPN connecting for an always on VPN setup, but I've recently changed to just doing host overrides in DNS to make it easier.
-
Trouble is the reply traffic.
You could have an OpenVPN set up between the sites with the remote public IP address as a remote network. Then port forward the outside:port to that address:port.
On the other side you would need to have an assigned interface on the OpenVPN to take advantage ot reply-to so replies would go back through OpenVPN and the states would work.
Chances are the forwarded destination is just a port forward anyway so all this forward this wan to that wan is moot anyway. You just need to forward connections into this WAN over OpenVPN to that LAN. OpenVPN works great there with reply-to.
-
Thanks guys,
Just wanted to mention that the reason I'm doing this is to hide the identity of 2.2.2.2 the other IP address on the internet where this site port 80 is hosted.
I would like 1.1.1.1 to be the main IP for some of my domains. Unfortunately, VPN is not an option at the moment.
Is there any better way of doing it other than port forwarding?
I have seen SOCAT linux utility do that before. But it's limited to single port forward on a session. But I have multiple IPs and ports.
Ron
-
Wow you have a public IP on the internet, but you want to hide it from the public internet.. Yet still use it to host stuff??
The weirdest tinfoil hat logic I have ever heard ;)
-
Trouble is the reply traffic.
You could have an OpenVPN set up between the sites with the remote public IP address as a remote network. Then port forward the outside:port to that address:port.
On the other side you would need to have an assigned interface on the OpenVPN to take advantage ot reply-to so replies would go back through OpenVPN and the states would work.
Chances are the forwarded destination is just a port forward anyway so all this forward this wan to that wan is moot anyway. You just need to forward connections into this WAN over OpenVPN to that LAN. OpenVPN works great there with reply-to.
outbound NAT solves the reply traffic issue youre speaking of.
firewall rule: allow inbound port 80 to dest host 2.2.2.2
port forward rule: port forward ANY source going to destination WAN IP destination port 80 to host 2.2.2.2 port 80
outbound NAT: WAN interface, nat source ANY destination 2.2.2.2 to WAN IP. -
Port forwarding in and out the same interface is hokey, at best.
Also lost is the source address of the end user at the destination site.
Might not matter to OP.
-
Can you say hairpin, can you say /2 bandwidth, can you say pointless in such a scenario.. Because he wants to hide his public IP?? WTF???
Why not just host what ever he is doing at IP 1.1.1.1?? Use less bandwidth this way.. Clients get better response, No hokey/borked setup and they don't know about IP 2.2.2.2 ;) which seems is the goal.
-
Update:
This has been solved and can be closed.
Can you say hairpin, can you say /2 bandwidth, can you say pointless in such a scenario.. Because he wants to hide his public IP?? WTF???
Why not just host what ever he is doing at IP 1.1.1.1?? Use less bandwidth this way.. Clients get better response, No hokey/borked setup and they don't know about IP 2.2.2.2 ;) which seems is the goal.
Yes, this would be a hairpin. It would half the throughput, but the load on said link is negligible. I really don't feel like arguing semantics, so im just going to leave it at hairpinning works just fine in pfsense.
He's unable to host locally, and the ultimate goal was to allow web servers to be dynamically provisioned and accessed without requiring constant DNS changes.
While it's possible to nat the traffic, there were other constraints that would not be met doing this method. The answer was setting up a reverse proxy, which also adds the benefit of acting as an accelerator.
