ClearFoundation Tracker - ClearOS
View Issue Details
0001113ClearOSapp-firewall - Firewallpublic2013-04-22 17:522019-04-24 08:27
user2 
 
lowminoralways
closedsuspended 
5.2-SP1 
 
0001113: 1:1 NAT and DMZ incompatibilities
Hosts behind ClearOS are able to connect to clients within the OpenVPN network so long as those hosts are not part of a 1:1 nat rule. The offending rule is:

SNAT all -- 192.168.1.168 anywhere to:10.10.10.11

Where 10.10.10.11 is the 1:1 external address and 192.168.1.168 is the internal host. This line should NOT say 'anywhere' because this forces all 1:1 Hosts involved to NAT the traffic even for normal routing between networks. Networks that should be excluded from this 'anywhere' statement should be:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
...and any network configured as a DMZ

Here is capture of ping packets from a working ping between the host and the OpenVPN client before the activation of the 1:1 rule:


[root@gen3 ~]# tcpdump -i tun0 icmp[icmptype]=icmp-echo
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
21:11:38.703316 IP 192.168.1.168 > 10.8.0.6: ICMP echo request, id 3, seq 15099, length 40
21:11:39.701630 IP 192.168.1.168 > 10.8.0.6: ICMP echo request, id 3, seq 15100, length 40
21:11:40.699847 IP 192.168.1.168 > 10.8.0.6: ICMP echo request, id 3, seq 15101, length 40

Here is the same test after the activation of the rule:

[root@gen3 ~]# tcpdump -i tun0 icmp[icmptype]=icmp-echo
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
21:15:08.467490 IP 10.10.10.11 > 10.8.0.6: ICMP echo request, id 3, seq 15234, length 40
21:15:13.105021 IP 10.10.10.11 > 10.8.0.6: ICMP echo request, id 3, seq 15235, length 40
21:15:17.742742 IP 10.10.10.11 > 10.8.0.6: ICMP echo request, id 3, seq 15236, length 40
21:15:22.380068 IP 10.10.10.11 > 10.8.0.6: ICMP echo request, id 3, seq 15237, length 40
What makes this difficult to test is that the socket caching of the NAT translation can cause a misreading on the activation of the NAT rule. This can make it so that activating the NAT rule while there is active or TTL traffic between the HOST and the OpenVPN client will persist even after an introduction of the rule in the table. A reboot between states is often required.

Another strategy is to stop the active ping traffic, make a sandwich or go to the bathroom and try the state again. The TTL should have expired.

Steps:
1- Setup and configure ClearOS 5.x as a gateway.
2- Have a server or host behind the gateway with services
3- Setup OpenVPN
4- Connect to server using OpenVPN from the outside and validate that you can ping the OpenVPN client
5- Stop ping
6- Create a 1:1 nat rule involving the host server's services.
7- Attempt to ping the OpenVPN client (If it pings, stop ALL pings and connections; may need a reboot or a sandwich before this fails)
WORKAROUND

If this is your 'iptable -t nat -L' entry for the POSTROUTING chain:

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 192.168.1.168 anywhere to:10.10.10.11
SNAT tcp -- 192.168.1.0/24 192.168.1.168 tcp dpts:ftp-data:ftp to:192.168.1.1
SNAT tcp -- 172.22.22.16/28 192.168.1.168 tcp dpts:ftp-data:ftp to:172.22.22.22
MASQUERADE all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere

Pay special attention to this line:
SNAT all -- 192.168.1.168 anywhere to:10.10.10.11

...and make the following edit to /etc/rc.d/rc.firewall.local:

# Custom firewall rules.
# This file is executed by the firewall on stop/start/restart.
iptables -t nat -D POSTROUTING -s 192.168.1.168 -j SNAT --to-source 10.10.10.11
iptables -t nat -I POSTROUTING -s 192.168.1.168 -d ! 10.0.0.0/8 -j SNAT --to-source 10.10.10.11
No tags attached.
related to 0001108closed  1:1 NAT breaks ability for OpenVPN clients to be accessed by internal NAT target server 
Issue History
2013-04-22 17:52user2New Issue
2013-04-22 17:52user2Issue generated from: 0001108
2013-04-22 17:52user2Relationship addedrelated to 0001108
2013-04-22 17:52user2Assigned To => user2
2013-04-22 17:52user2Statusnew => confirmed
2018-12-14 12:11user2Statusconfirmed => assigned
2018-12-14 12:11user2Assigned Touser2 => tracker
2019-04-24 08:27NickHNote Added: 0011611
2019-04-24 08:27NickHStatusassigned => closed
2019-04-24 08:27NickHAssigned Totracker =>
2019-04-24 08:27NickHResolutionopen => suspended

Notes
(0011611)
NickH   
2019-04-24 08:27   
Migrated to https://gitlab.com/clearos/clearfoundation/app-firewall/issues/7 [^]