Anonymous | Login | 2024-12-22 00:04 MST |
Main | My View | View Issues | Change Log | Roadmap | Repositories |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001113 | ClearOS | app-firewall - Firewall | public | 2013-04-22 17:52 | 2019-04-24 08:27 | ||||
Reporter | user2 | ||||||||
Assigned To | |||||||||
Priority | low | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | suspended | ||||||
Platform | OS | OS Version | |||||||
Product Version | 5.2-SP1 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0001113: 1:1 NAT and DMZ incompatibilities | ||||||||
Description | 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 | ||||||||
Steps To Reproduce | 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) | ||||||||
Additional Information | 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 | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | ||||||
|
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 |