| Anonymous | Login | 2024-12-21 23:38 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 | ||||
| 0019431 | ClearOS | app-ipsec - IPsec Engine | public | 2018-03-22 06:04 | 2019-02-26 11:58 | ||||
| Reporter | NickH | ||||||||
| Assigned To | |||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | closed | Resolution | suspended | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | 7.4.0 | ||||||||
| Target Version | 7.6.0 Updates | Fixed in Version | |||||||
| Summary | 0019431: Dynamic IPsec VPN meta-bug | ||||||||
| Description | I'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" | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0007531) NickH (developer) 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 (developer) 2019-02-26 11:57 |
Migrated to: https://gitlab.com/clearos/clearfoundation/app-ipsec/issues/1 [^] |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2018-03-22 06:04 | NickH | New Issue | |
| 2018-03-22 07:09 | user2 | Status | new => confirmed |
| 2018-06-04 08:11 | NickH | Note Added: 0007531 | |
| 2019-02-26 05:20 | NickH | Target Version | => 7.6.0 Updates |
| 2019-02-26 11:57 | NickH | Note Added: 0010321 | |
| 2019-02-26 11:58 | NickH | Status | confirmed => closed |
| 2019-02-26 11:58 | NickH | Resolution | open => suspended |
|
Issue History |