Double NAT and ORANGE unreachable from GREEN using external IP or domain

Networking
1

Good morning everyone,

I am having significant difficulties configuring my IPFire following a change of internet provider. I kindly ask for your help.

I’ll try to briefly explain the situation. I’ll start with a description of the internal network and the fact that before the provider change, everything worked perfectly.

I have configured 3 zones: RED, GREEN (192.168.50.0/23), and ORANGE (192.168.60.0/24). In the ORANGE zone, I have a server with a file-sharing service listening on port 443.

Until a few days ago, the RED zone connected to the internet via PPPoE (with credentials), directly obtaining the static public IP address. In that situation, I had no problem reaching the file-sharing service both from outside (internet, via port forwarding) and from machines connected to the GREEN zone, using the public static IP.

After changing the internet provider (I switched to a fiber optic connection), I now have the provider’s router as the first device in the network. The WAN port of this device faces the internet and has the public static IP address (associated with a second-level domain I own, such as mydomain.it). One of the router’s LAN ports (192.168.1.0/24) is connected to the IPFire ethernet associated with the RED zone. The RED zone now has the static address 192.168.1.10 and gateway 192.168.1.1 (the LAN address of the provider’s router).

In this situation, I can no longer reach the server in the ORANGE zone from machines connected to the GREEN zone using the domain (and therefore the external static IP; everything works if I use the internal IP directly 192.168.60.239:443).

The problem is evidently the double NAT, which I have not been able to solve in any way.

I tried configuring IPFire as a DNS server for the GREEN zone and modifying the hosts file to map the file-sharing server address to the domain (192.168.60.239 mydomain.it) but it didn’t work (the domain continues to resolve to the external address, i do not know why).

I would like to create a firewall or routing rule to manage the situation but have not been able to.

I must clarify that I cannot configure the provider’s router in bridge mode, so I have to deal with the double NAT.

Does anyone have any suggestions?

Thank you in advance!

2

What is the model of this router ?
Can you configure DMZ in your ISP router ?

Regards

1 Like
3

I do not have access to the provider’s router configuration. I have requested port forwarding of all ports from the outside to the address 192.168.1.10 (the IPFire RED interface address). From the outside, the port forwarding works without any problem, and I can reach all internal services. The issue only occurs from GREEN to ORANGE.

Currently, I am not in the office and do not have the router on hand. I will retrieve the brand and model if possible.

Thank you!

4

If the ISP router does not support hairpin mode, then using your external address internally is going to fail. The obvious way round that is split DNS. Externally you’ll need a port forward at the ISP router to IPFire and a further port forward in IPFire

The way round it, possibly, is to use split DNS, so internally on your LAN, the FQDN resolves to the correct internal IP, but externally it resolves to your external IP. But, normally for this, you would not use your domain directly for this but a machine name on your domain and have that resolve differently internally and externally. It means internal machines will have to use IPFire as their DNS server (or the hosts file if they are permanently on your LAN).

Technically, you can probably do a modified port forward in IPFire. You’d need to pick all packets with destination to your WAN IP with the relevant port and protocol selected. Try using the Destnation Address for that. You’d also need an SNAT rule to SNAT the packet destined for the Orange LAN to the Green IP.

5

Good morning Nick, thank you for your suggestions.
It seems I have made some progress with the following routing rule:

iptables -t nat -A PREROUTING -s 192.168.50.0/24 -d external_IP -p tcp --dport 443 -j DNAT --to-destination 192.168.60.239:443

inserted directly from the shell. From the logs, I see that the packets are being forwarded, and indeed from one of the machines in the GREEN zone, it appears that I can reach the service. From other machines, I am having trouble resolving the external address using the domain, but it might be due to something incorrect I did previously while modifying the hosts file, etc. I will try to look into it further.
In any case, any suggestions are welcome!

6

Remember you also need an SNAT rule. probably something like:

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -d 192.168.60.239 -p tcp --dport 443 -j SNAT --to-source 192.168.50.1

assuming 192.168.50.1 is your Green LAN IP. This stops replies from 192.168.60.239 going straight back to the source IP where they would be rejected because the source IP never sent anything to 192.168.60.239, they sent it to your WAN IP via the Green LAN IP.

You should be able to do both rules from the GUI. Also, in your rule you don’t need to specify the port in your --to-destination. If not specified, it keeps it the same.

If this works, sorting the hosts file won’t matter. What do you have in your hosts file? Are you trying to resolve the domain or a subdomain for the machine. Resolving the domain could be a tricky way to go if you sometimes want it to resolve to your IPFire or router.

1 Like
7

Good evening Nick, and thank you so much for your help. The prerouting rule I added seems to have resolved the issue. In any case, I will try to verify the system’s behavior by also adding the rule you suggested. However, I have a doubt regarding this: the address 192.168.50.1 is the one associated with the ethernet card of the GREEN zone of my IPFire. Does this seem correct to you? Did you mean to indicate the gateway of that zone in your rule? I ask because it is not clear to me how it should work to manage requests coming from different PCs within the zone (and therefore from different IPs).

In my hosts file, I had added the line
192.168.60.239 mydomain.it
which I have now removed.

On Monday, I will conduct more in-depth tests: today I was out of the office and could only work via VPN.

Thanks again for your help!

8

Thinking more about it, you may not need that rule. It is only needed for traffic from one machine in the LAN to another machine on the same LAN.

9

Well, you request that the modem be bridged out. Sometimes you can do this in the modem page 192.168.100.1 in some modems. Other times, they deactivate the router portion and bridge out the connection.

10

Unfortunately have no access to modem configuration. However fixed the problem with the suggested SNAT rules. Thx!

11

no problem wished I could get fibre since I can program a SPF+ module and bypass their ont/modem box. But my isp was one of those cable companies that is still in the dark ages.