ClearFoundation Tracker - ClearOS
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0019431ClearOSapp-ipsec - IPsec Enginepublic2018-03-22 06:042019-02-26 11:58
ReporterNickH 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Version7.4.0 
Target Version7.6.0 UpdatesFixed in Version 
Summary0019431: Dynamic IPsec VPN meta-bug
DescriptionI'm opening this bug to track issues and enhancements with the Dynamic VPN app.

1) In order to maintain compatibility with the Static IPsec VPN app, in /etc/ipsec.conf, in "config setup" add "interfaces=%defaultroute". It has no effect on the Dynamic VPN but if someone then moves over to the Static VPN this could be needed for one of the options but ipsec.conf will probably not be updated.

2) In the same section, remove the lines "oe=off" and "nat_traversal=yes". They have both been deprecated and are the defaults now. They just put warnings into the log file now.

3) In "conn default" remove the references to the updown scripts and, if necessary, put them in the individual conns. Currently the ClearOS updown script breaks ikev2 tunnels that you can configure in the Static VPN, but the default script works fine with ikev2. The Static VPN has no way of overriding any scripts.

4) Review the ClearOS updown script is it is now somewhat out of step with upstream. Is it necessary? (See the note on sourceip's in 5)

5) In the dynamic conns, also add the left/rightsourceip to the config (but only needed for the local end). This is the way to add the routing from the local tunnel endpoint to the remote side. E.g, if the local ClearOS LAN IP is 192.168.1.1 and subnet is 192.168.1.0/24, without a local source IP set, a ping from ClearOS to the remote end will go straight from the WAN interface and fail. With a sourceip set, the ping will come from 192.168.1.1 and work. This should be the same for all server-server traffic. I have a feeling this is covered by the ClearOS updown script but should be unnecessary if native *swan fuctionality is used. Also if both left and rightsourceip's are provisioned programatically from the dynamic VPN you automatically get your ping targets to see if the tunnel is up.

6) Review the use of marking in the iptables mangle table PREROUTING chain of the esp packets. It may be causing a bug with the QoS app which also uses marking. From the testing I have done (as I don't have a remote LAN to test with), the marking is used in three rules, two in the INPUT chain and one in the FORWARD chain. Removing the marking and using:
     "iptables -I INPUT -m policy --dir in --pol ipsec -j ACCEPT"
could possibly replace the rule in the INPUT chain but I don't know if it is safe as it opens up the WAN interface to all "--pol ipsec" packets. I *think* it is OK but it depends if normal external packets can arrive with the ipsec policy set which I doubt. In the FORWARD chain, the following rule appears to work:
     "iptables -I FORWARD -m policy --dir in --pol ipsec -j ACCEPT"
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2018-03-22 06:04NickHNew Issue
2018-03-22 07:09user2Statusnew => confirmed
2018-06-04 08:11NickHNote Added: 0007531
2019-02-26 05:20NickHTarget Version => 7.6.0 Updates
2019-02-26 11:57NickHNote Added: 0010321
2019-02-26 11:58NickHStatusconfirmed => closed
2019-02-26 11:58NickHResolutionopen => suspended

Notes
(0007531)
NickH   
2018-06-04 08:11   
With the testing I've done and also had done on ticket 558446 the following rules are needed:
iptables -I INPUT -m policy --dir in --pol ipsec -j ACCEPT
iptables -I FORWARD -m policy --dir in --pol ipsec -j ACCEPT

These replace the current:
iptables -I PREROUTING -t mangle -p esp -j MARK --set-mark 0x64
iptables -I INPUT -m mark --mark 0x64 -d clearos_wan_ip -j ACCEPT
iptables -I INPUT -m mark --mark 0x64 -d clearos_lan_ip -j ACCEPT
iptables -I FORWARD -m mark --mark 0x64 -j ACCEPT

These have the advantage of being generic so don't have to be reset if either the LAN IP or WAN IP changes so can be made permanent or, optionally, can be activated when the incoming firewall Service IPsec is activated in the firewall.

Also suggested by Libreswan, there are two POSTROUTING rules which can be combined:
iptables - I POSTROUTING -t nat -m policy --dir out --pol ipsec -j ACCEPT
iptables - I POSTROUTING -t nat -o WAN_interface -j MASQUERADE

These can be combined to a single rule:
iptables - I POSTROUTING -t nat -m policy --dir out --pol none -o WAN_interface -j MASQUERADE

The only issue I see with combining these now are the new docker POSTROUTING rules which may also need the "-m policy --dir out --pol none" adding.
(0010321)
NickH   
2019-02-26 11:57   
Migrated to: https://gitlab.com/clearos/clearfoundation/app-ipsec/issues/1 [^]