This has been observed by myself and @luizluca: ip route get is
appending uid0 to the output, as seen from:
root@OpenWrt2:~# ip route get 1.1.1.1
1.1.1.1 via 174.27.160.1 dev eth3 src 174.27.182.184 uid 0
cache
root@OpenWrt2:~#
so the fix is an anchored match, discarding all else. Also, using
ip -o means never having to do multiline matches...
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
This commit allows for UCI configuration of the "left=" and the
"mark=" values in a StrongSwan IPSec connection. This improves
VTI support and allows certain stricter connection scenarios.
Signed-off-by: Michael C. Bazarewsky <github@bazstuff.com>
This is useful to assign all traffic to a fw3 zone, e.g.:
/etc/config/ipsec:
config remote 'test'
list tunnel 'dev'
...
config 'tunnel' 'dev'
option reqid '33'
...
/etc/config/firewall:
config zone
option name wan
option extra_src "-m policy --pol none --dir in"
option extra_dest "-m policy --pol none --dir out"
...
config zone
option name vpn
# subnet needed for firewall3 before 22 Nov 2019, 8174814a
list subnet '0.0.0.0/0'
option extra_src "-m policy --pol ipsec --dir in --reqid 33"
option extra_dest "-m policy --pol ipsec --dir out --reqid 33"
...
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
The interface config option allows users to configure logical OpenWRT
interface names in the ipsec section; it allows StrongSwan to listen
and send traffic on specified interface(s). It translates to interfaces_use
StrongSwan option which is a comma sepearted list of network devices
that should be used by charon.
Since StrongSwan can only be started when one of the specified logical
OpenWRT interface is up procd interface triggers are installed to
trigger the reload script.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Based on the ipsec running state reload_service is either reloading ipsec
or starting ipsec. However in the latter case it calls ipsec start which
bypasses the procd start_service function which means the running ipsec
instance is not managed by procd.
Fix this by calling start in case ipsec is not running; at the same time
add service_running function which is used by procd provided running
function.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
When the strongswan service is running, `ipsec status` returns 0. Check
the return value instead of checking its output.
While at it, remove the [[ ]] bashism, use rereadall instead of
(reread)secrets, and move it inside the if statement.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
In commit 36e073d820, some checks were
added to see if the UCI config file exists and if there are any peers
configured in it. Due to these checks, if /etc/config/ipsec exists, but
contains no enabled peers, strongswan will not be started. This is not
ideal, as a user might want to experiment with the UCI config while
keeping existing connections in /etc/ipsec.conf operational.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Add support to configure strongswan via uci.
uci support is based on the following sections
-ipsec : Global config items belonging in the strongswan.conf file
-remote : Defines the remote peer(s)
-tunnel : Defines the IPSec connections in tunnel mode
-transport : Defines the IPSec connections in transport mode
-crypto_proposal : Defines the different crypto proposals
Signed-off-by: Pierre Lebleu <pme.lebleu@gmail.com>
Signed-off-by: Gino Peeters <peeters.gino@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Philip Prindeville