A
A
Alexander2018-04-13 17:51:46
FreeBSD
Alexander, 2018-04-13 17:51:46

Windows behind double NAT, how to route traffic correctly?

Hello.
We have Proxmox with an external IP address, it has three Windows Server 2016 and FreeBSD as a gateway for them (needed for the GRE over IPsec scheme). NAT (masquerade) occurs between Proxmox and FreeBSD (via iptables) and between FreeBSD and Windows servers (via pf). Packet filters are disabled in both routers, routing is enabled.
The problem is that FreeBSD has no problems, even GRE with IPsec is raised through NAT, and only ping passes with Windows. That is, I can ping 8.8.8.8, but I can't get a DNS response from it; a ping to other server behind the remote gateway goes, RDP - is not present.
Interestingly, Proxmox's tcpdump of the external interface shows that requests from FreeBSD leave with the external source IP, and the same requests from Windows go with the internal one, which was reattached once, i.e. as if the second NAT did not occur. Interestingly, even inside the GRE tunnel, when GRE packets are already being pulled, Windows crashes.
Where could be the problem? In iptables, a banal postrouting masquerade based on source IP is easy on FreeBSD nat on wan all -> wan. Maybe I'm wildly dumb and don't see something obvious, or I just don't know the technology well enough.
Thank you.
PS
tcpdump output: the first 8 lines are obviously pings, the last 5 are nslookup ya.ru 8.8.8.8, all from a Windows server. Very strange.
~# tcpdump -n host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:25:40.687072 IP xx203.43 > 8.8.8.8: ICMP echo request, id 4854, seq 74, length 40
18:25:40.715676 IP 8.8.8.8 > xx203.43: ICMP echo reply, id 4854, seq 74, length 40
18:25:41.695257 IP xx203.43 > 8.8.8.8: ICMP echo request, id 4854, seq 75, length 40
18:25:41.723833 IP 8.8.8.8 > xx203.43: ICMP echo reply, id 4854, seq 75, length 40
18:25:42.710761 IP xx203.43 > 8.8.8.8: ICMP echo request, id 4854, seq 76, length 40
18:25:42.739347 IP 8.8.8.8 > xx203.43: ICMP echo reply, id 4854, seq 76, length 40
18:25:43.726352 IP xx203.43 > 8.8.8.8: ICMP echo request, id 4854, seq 77, length 40
18:25:43.754949 IP 8.8.8.8 > xx203.43: ICMP echo reply, id 4854, seq 77, length 40
18:26:06.450895 IP 10.6.100.2.56611 > 8.8.8.8.53: 1+ PTR? 8.8.8.8.in-addr.arpa. (38)
18:26:08.462490 IP 10.6.100.2.58269 > 8.8.8.8.53: 2+ A? ya.ru. (23)
18:26:10.462353 IP 10.6.100.2.65350 > 8.8.8.8.53: 3+ AAAA? ya.ru. (23)
18:26:12.477537 IP 10.6.100.2.55766 > 8.8.8.8.53: 4+ A? ya.ru. (23)
18:26:14.494460 IP 10.6.100.2.60016 > 8.8.8.8.53: 5+ AAAA? ya.ru. (23)
NAT iptables output on Proxmox:
~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt ​​source destination
DNAT tcp -- anywhere anywhere tcp dpt:ssh to:10.6.100.2
Chain INPUT (policy ACCEPT)
target prot opt ​​source destination
Chain OUTPUT (policy ACCEPT)
target prot opt ​​source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt ​​source destination
MASQUERADE all -- 10.6.100.0/30 anywhere
10.6.100.0/30 is the network between FreeBSD and Proxmox.

Answer the question

In order to leave comments, you need to log in

1 answer(s)
A
Alexander, 2018-04-16
@Adorne

As usual, I decided (if I can call it that) myself.
I set up a white address, it didn’t even work, although now Windows packages with a white source address went to the Internet. Resetting the config to zero did not help, but a clean install helped, and the only difference from the previous one was that the network cards were not virtio, but Intel E1000. Works like clockwork.
For the sake of experiment, I tried with a white address and Debian virtio-maps - it went right away.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question