firewall - NAT translating internal-to-internal communication 2

[postwick]

I have a Redhat 8 firewall set up doing NAT for my two servers. Each has its own NAT rules for incoming and outgoing packets. I am also masquerading a few IPs for desktops to access the Internet.

One of the servers is a web server that needs to connect to the other server, a database server. Both are Linux servers. When the web server tries to connect to the db server, the db server sees the web server as its external IP address instead of its internal. Why is internal-to-internal communication being translated? How can I avoid this?

-- Paul

 

[Norwich]

You should be NATing on the external interface of the firewall box. Also, it is a good idea to put a web server in a DMZ.

 

[postwick]

The iptables in Linux don't really work like that as far as I can tell - the NATing on a specific interface. As for a DMZ, that's all overkill for me.

My main question is why are packets for the local LAN getting sent to the default gateway, and how do I stop it from happening?

 

[Norwich]

I cant' say unless you give me a detailed layout plan of the network and the gateway settings etc of the machines....

As for NATing to masquarade a network - that's what it is - hiding the machines behind ONE interface.

 

[postwick]

here's what I've got...

internet ---> DSL ---> DSL modem ---> ext eth1 (65.1.1.254) ---> int eth0 (10.1.1.254) ---> LAN

I have two servers on the LAN, we'll call them 10.1.1.10 and 10.1.1.11 (gateways are 10.1.1.254). They have static NATed internet IP addresses of 65.1.1.10 and 65.1.1.11. I also have two desktops on the LAN, 10.1.1.20 and 10.1.1.21 (gateways are 10.1.1.254) that simply need internet access and share 65.1.1.12 using NAT masquerading.

When 10.1.1.10 tries to communicate with 10.1.1.11, the packets are received by 10.1.1.11 as if they came from 65.1.1.10, the NATed address of 10.1.1.10.

Why are the internal packets going to the firewall at all? Why don't the two internal servers simply connect directly?

-- Paul

 

[postwick]

Here is the result of 'ip route list' on 10.1.1.10:

65.1.1.0/24 dev eth0 proto kernel scope link src 65.1.1.10
10.1.1.0/24 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 10.1.1.254 dev eth0

Here is the result of 'ip route list' on 10.1.1.11:

65.1.1.0/24 dev eth0 proto kernel scope link src 65.1.1.11
10.1.1.0/24 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 10.1.1.1.254 dev eth0

From the firewall...
65.1.1.0/24 dev eth1 scope link
10.1.1.0/24 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 65.1.1.1 dev eth1

(65.1.1.1) is the gateway for my DSL ISP.

From the firewall, an 'iptables -t nat -L -v':

PREROUTING
DNAT tcp -- any any anywhere 65.1.1.10 to:10.1.1.10
DNAT tcp -- any any anywhere 65.1.1.11 to:10.1.1.11
DNAT udp -- any any anywhere 65.1.1.10 udp dpt:domain to:10.1.1.10
DNAT udp -- any any anywhere 65.1.1.11 udp dpt:domain to:10.1.1.11

POSTROUTING
SNAT tcp -- any any 10.1.1.11 anywhere to:65.1.1.11
SNAT tcp -- any any 10.1.1.10 anywhere to:65.1.1.10
MASQUERADE all -- any any 10.1.1.0/24 anywhere

 

[Norwich]

I'm not too hot on iproute2 so could you paste the results of "ifconfig" and "route" from all three machines.

 

[Norwich]

Also, how are you referencing the database server from the web server - by IP address or by name? If by name, how are you providing name resolution and what's the resolution method order on the web server.

 

[Norwich]

Also, how do you determine that the db server is interpretting the source as 65.1.1.whichever.

 

[postwick]

I'll post the results of the other commands later when I have time. I am referencing the database from the web server by IP address. The reason I know the db is seeing the web server as the 65.1.1.10 instead of 10.1.1.10 is that PostgreSQL originally complained that there is no pg_hba.conf entry for 65.1.1.10 and the web server can't connect.

 

[postwick]

Decided to make time...

Here's 'route -v' from 10.1.1.10
65.1.1.0 * 255.255.255.0 U 0 0 0 eth0
10.1.1.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 10.1.1.254 0.0.0.0 UG 0 0 0 eth0

from 10.1.1.11
65.1.1.0 * 255.255.255.0 U 0 0 0 eth0
10.1.1.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 10.1.1.254 0.0.0.0 UG 0 0 0 eth0

from firewall
65.1.1.0 * 255.255.255.0 U 0 0 0 eth1
10.1.1.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 65.1.1.1 0.0.0.0 UG 0 0 0 eth1


I suspect my problem lies in the first route for each of the first two servers (65.1.1.0 *). Before I put the firewall up, I had the external IP addresses assigned directly to the NIC in both servers. However, if I take that route out of each system, they cannot communicate at all.

 

[Norwich]

Hi,

That's why I asked for the result of "ifconfig" for each machine - I'm mondering if you've got IP aliases on the servers.

 

[postwick]

ifconfig from 10.1.1.10:

eth0 Link encap:Ethernet HWaddr 00:10:5A:E43:52
inet addr:65.1.1.10 Bcast:65.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:51572 errors:0 dropped:0 overruns:0 frame:0
TX packets:47940 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:31176913 (29.7 Mb) TX bytes:10132330 (9.6 Mb)
Interrupt:10 Base address:0xfc00

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:5367 errors:0 dropped:0 overruns:0 frame:0
TX packets:5367 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:664802 (649.2 Kb) TX bytes:664802 (649.2 Kb)


ifconfig from 10.1.1.11
eth0 Link encap:Ethernet HWaddr 00:A0:24:51:6E7
inet addr:65.1.1.11 Bcast:65.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16476 errors:0 dropped:0 overruns:0 frame:0
TX packets:11521 errors:0 dropped:0 overruns:0 carrier:0
collisions:24 txqueuelen:100
RX bytes:13592899 (12.9 Mb) TX bytes:1441449 (1.3 Mb)
Interrupt:10 Base address:0xdc00

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:532 errors:0 dropped:0 overruns:0 frame:0
TX packets:532 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:42222 (41.2 Kb) TX bytes:42222 (41.2 Kb)


now that's interesting. where are the 10.1.1.x addresses?

 

[Norwich]

Mate - eth0 on 10.1.1.10 isn't - it's 65.1.1.10

same for eth0 on 10.1.1.11 - that's 65.1.1.11

Somehow you've got 10.1.1.10 and 10.1.1.11 set up as aliases - were there eth0:0 interfaces on both machines?

Anyway - change the IP address on each machine's eth0 to the 10.1.1.0 subnet and loose the aliases.

There shouldn't be any public IP addresses floating around in the private network - all D and S NAT traslation taking part at the firewall.

(However, if there is public sourced packets coming in from outside, I would still argue that a DMZ is inherently more safe - and you could use the 65.1.1.0 addresses on DMZ if you own the appropriate subnet for all public interfaces).

 

[postwick]

I've spent days getting this all set up and this was the last bug I had to work out. I don't know a ton about routing, and this one had me stumped. You are my savior! Thanks for the help.