ClearOS Bug Tracker


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001113ClearOSapp-firewall - Firewallpublic2013-04-22 17:522019-04-24 08:27
Reporteruser2 
Assigned To 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Version5.2-SP1 
Target VersionFixed in Version 
Summary0001113: 1:1 NAT and DMZ incompatibilities
DescriptionHosts 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
Steps To ReproduceWhat 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)
Additional InformationWORKAROUND

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
TagsNo tags attached.
Attached Files

- Relationships
related to 0001108closed 1:1 NAT breaks ability for OpenVPN clients to be accessed by internal NAT target server 

-  Notes
(0011611)
NickH (developer)
2019-04-24 08:27

Migrated to https://gitlab.com/clearos/clearfoundation/app-firewall/issues/7 [^]

- Issue History
Date Modified Username Field Change
2013-04-22 17:52 user2 New Issue
2013-04-22 17:52 user2 Issue generated from: 0001108
2013-04-22 17:52 user2 Relationship added related to 0001108
2013-04-22 17:52 user2 Assigned To => user2
2013-04-22 17:52 user2 Status new => confirmed
2018-12-14 12:11 user2 Status confirmed => assigned
2018-12-14 12:11 user2 Assigned To user2 => tracker
2019-04-24 08:27 NickH Note Added: 0011611
2019-04-24 08:27 NickH Status assigned => closed
2019-04-24 08:27 NickH Assigned To tracker =>
2019-04-24 08:27 NickH Resolution open => suspended