Re: [strongSwan] remote peer IP falls into crypto domain right subnet

[Phil Frost]

There are other possible solutions, but my inclination would be to run
strongswan and any other VPN related services in a distinct network
namespace. This would not only address your issue, but it also prevents
accidentally "crossing the streams" between the VPN and other public
networks to which the host is attached. A common issue is the IKE daemon
fails to start or is misconfigured, and so the policies that normally
encrypt traffic on egress don't get installed, and traffic that should have
been encrypted is leaked on a public interface.

https://vincent.bernat.ch/en/blog/2017-route-based-vpn is a tutorial I've
found helpful in the past. It covers BGP and a lot of other things beyond
your particular problem, but maybe ignoring those parts you may still find
it useful.

On Wed, Sep 26, 2018 at 3:01 PM Doug Tucker 
wrote:

> I've done some searching and am not finding any info on this.  We had a
> client who wanted to offer a /16 as his right subnet and his outside peer
> IP of his ASA fell into the /16 they were offering.  With a cisco ASA this
> is a non issue as in this type of scenario cisco exempts out that single IP
> from the routing table but with strongswan 5.6.3 it appears to not do so by
> default and caused some odd routing anomalies to this IP.  Does anyone know
> of a configuration directive for dealing with this?
>
>
> *Doug Tucker*
>
> Sr. Network Administrator
>
> *o: *817.975.5832 <(817)%20975-5832>*  |  *m: 817.975.5832
> <(817)%20975-5832>
>
> *e:* doug.tuc...@newscycle.com
>
>
>
> [image: Newscycle Solutions] 
>
> *Breakthrough technologies for media*
>
>
>
> *Twitter **  |  Facebook
>   |  Linkedin
> *
>
>
>
> CONFIDENTIALITY NOTICE: The contents of this email message and any
> attachments are intended solely for the addressee(s) and may contain
> confidential and/or privileged information and may be legally protected
> from disclosure. If you are not the intended recipient of this message or
> their agent, or if this message has been addressed to you in error, please
> immediately alert the sender by reply email and then delete this message
> and any attachments. If you are not the intended recipient, you are hereby
> notified that any use, dissemination, copying, or storage of this message
> or its attachments is strictly prohibited.
>
>

Re: [strongSwan] Intermittent MTU issue

[Phil Frost]

On Fri, Jun 1, 2018 at 11:51 AM Noel Kuntze
 wrote:

> >
> > I'd also check that under no circumstances can the hosts exchange
> unencrypted traffic. This can happen for example if the tunnel goes down
> and there's nothing to block unencrypted traffic. "auto=route" is a good
> idea, as is blocking everything besides ESP with iptables.
> If you do that, nothing will work, because decapsulated packets are
> subject to iptables rules, too.
>

You're right, I hadn't considered a policy based tunnel. All of the tunnels
I administer use dynamic routing and a vti: the rules that block
unencrypted traffic apply only to the ethernet interface. (Incidentally the
tunnel interface makes packet captures easier.)

"auto=route" should work regardless.

Re: [strongSwan] Intermittent MTU issue

[Phil Frost]

On Tue, May 29, 2018 at 12:05 PM Arzhel Younsi  wrote:

> How to troubleshoot it more?
>

Another method is to capture the encrypted traffic normally, and then grab
the encryption keys from the kernel and decrypt the traffic in Wireshark.
The keys currently in use can be viewed with "ip xfrm state", or I believe
if the "charondebug" setting in ipsec.conf is set with enough verbosity,
the keys will get logged as they are exchanged via IKE.

I would wonder how big these spikes are. It could be normal path discovery
activity.

I'd also check that under no circumstances can the hosts exchange
unencrypted traffic. This can happen for example if the tunnel goes down
and there's nothing to block unencrypted traffic. "auto=route" is a good
idea, as is blocking everything besides ESP with iptables.

Re: [strongSwan] Forcing all traffic from a specific user to use Strongswan

[Phil Frost]

To check your routing tables, you can use `ip route get SOME_IP_ADDRESS`.

You can also inspect the routing tables with `ip route`. One non-obvious
thing is strongswan may install an additional route table. You can see all
the tables that exist with `ip rule`. The one strongswan makes is called
simply "220". `ip route` will show the main table, and the 220 table can be
show with `ip route list table 220`. With the usual way the rules are set
(ip rule), anything in table 220 will override the main table.

In my case I found it best to disable strongswan's management of the route
table and ip addresses with the `charon.install_routes = no` and
`charon.install_virtual_ip = no` settings. I handle all of it in my own
networking scripts.

On Thu, May 24, 2018 at 11:24 AM Gilles Printemps 
wrote:

> Some updates.
> I'm now able to create the vti interface and I have an address assigned to
> the vti
>
> Result of "ifconfig"
> vti0  Link encap:IPIP Tunnel  HWaddr
>   inet addr:10.3.188.149  P-t-P:10.3.188.149  Mask:255.255.255.255
>   UP POINTOPOINT RUNNING NOARP  MTU:1332  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> Can someone confirm I have now to route all the marked packets to this
> interface to go through the VPN?
> if the address assigned to the vti can be seen as a gateway for the VPN?
>
>
> FYI, following files have been updated.
>
> [/etc/ipsec.conf]
>
>> conn VPN
>> keyexchange=ike
>> dpdaction=clear
>> dpddelay=300s
>>
> leftupdown=/etc/ipsec.script.sh
>> left=%defaultroute
>> leftsourceip=%config4
>> leftauth=eap-mschapv2
>> eap_identity=gprintemps
>> right=free-nl.hide.me
>> rightauth=pubkey
>> rightid=%any
>> rightsubnet=0.0.0.0/0
>> auto=route
>> mark=2
>
>
> [/etc/ipsec.script.sh]
>
>> #!/bin/bash
>> set -o nounset
>> set -o errexit
>> VTI_IF="vti0"
>> case "${PLUTO_VERB}" in
>> up-client)
>> ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote
>> "${PLUTO_PEER}" mode vti \
>>   okey "${PLUTO_MARK_OUT%%/*}" ikey
>> "${PLUTO_MARK_IN%%/*}"
>> ip link set "${VTI_IF}" up
>> sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1"
>> ip addr add ${PLUTO_MY_SOURCEIP} dev "${VTI_IF}"
>> ;;
>> down-client)
>> ip tunnel del "${VTI_IF}"
>> ;;
>> esac
>
>
>
> On Thu, May 24, 2018 at 12:15 PM, Gilles Printemps 
> wrote:
>
> I already prepared the next step (after fixing the current issue), I've
>> created the following script
>>
>> #! /bin/bash
>>> export TABLE_ID="vpn"
>>> export VPN_USER="vpn"
>>> export VPN_INTERFACE="vti0"
>>> export LAN="10.211.55.0/24"
>>>
>>> # Flush iptables rules
>>> iptables -F -t nat
>>> iptables -F -t mangle
>>> iptables -F -t filter
>>> # Mark packets from $VPN_USER
>>> iptables -t mangle -A OUTPUT ! --dest $LAN  -m owner --uid-owner
>>> $VPN_USER -j MARK --set-mark 0x1
>>> iptables -t mangle -A OUTPUT ! --src $LAN -j MARK --set-mark 0x1
>>> # Deny $VPN_USER to access other interfaces than lo
>>> iptables -A OUTPUT ! -o lo -m owner --uid-owner $VPN_USER -J DROP
>>> # Allow $VPN_USER to access lo and VPN interfaces
>>> iptables -A OUTPUT -o lo -m owner --uid-owner $VPN_USER -j ACCEPT
>>> iptables -A OUTPUT -o $VPN_INTERFACE -m owner --uid-owner $VPN_USER -j
>>> ACCEPT
>>>
>>> # Allow response from $VPN_INTERFACE
>>> iptables -A INPUT -i $VPN_INTERFACE -m conntrack --ctstate ESTABLISHED
>>> -j ACCEPT
>>> # Masquarade packets on $VPN_INTERFACE
>>> iptables -t nat -A POSTROUTING -o $VPN_INTERFACE -j MASQUERADE
>>>
>>> # Routing rules
>>> ip route replace default via $GATEWAY table $TABLE_ID
>>> ip route append default via 127.0.0.1 dev lo table $TABLE_ID
>>> ip route flush cache
>>
>>
>> Purpose to is mark all packets from VPN_USER and to redirect them to the
>> ipsec interface created by the the configuration
>> I'm planning to do it with the following command:
>>
>>> ip rule add from all fwmark 0x1 lookup vpn
>>
>>
>> Best Regards,
>> Gilles
>>
>>
>

Re: [strongSwan] Forcing all traffic from a specific user to use Strongswan

[Phil Frost]

It looks like the leftupdown option is set to run some other script than
the one you created.

On Fri, May 18, 2018, 05:26 Gilles Printemps <gprinte...@gmail.com> wrote:

> Hi Phil, All
> I tried to look for some details how to implement a route based VPN and
> I've created the following configuration
>
> First, I've created the following script which will be called by the VPN
> at the start/end of the connection
> As a test, I tried to route only 172.217.19.69 (it's one of the google
> addresses)
> [/etc/ipsec.script.sh]
>
> #!/bin/bash
>> set -o nounset
>> set -o errexit
>> VTI_IF="vti${PLUTO_UNIQUEID}"
>> case "${PLUTO_VERB}" in
>> up-client)
>> ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote
>> "${PLUTO_PEER}" mode vti \
>> okey "${PLUTO_MARK_OUT%%/*}" ikey "${PLUTO_MARK_IN%%/*}"
>> ip link set "${VTI_IF}" up
>> ip addr add ${PLUTO_MY_SOURCEIP} dev "${VTI_IF}"
>> ip route add 172.217.19.68/32 dev "${VTI_IF}"
>> sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1"
>> ;;
>> down-client)
>> ip tunnel del "${VTI_IF}"
>> ;;
>> esac
>
>
> and the IPSec configuration [etc/ipsec.conf]
>
> conn hide-nl
>>keyexchange=ike
>>dpdaction=clear
>>dpddelay=300s
>>eap_identity=gprintemps
>>leftupdown=/usr/local/sbin/ipsec-notify.sh
>>leftauth=eap-mschapv2
>>left=%defaultroute
>>leftsourceip=%config
>>right=free-nl.hide.me
>>rightauth=pubkey
>>rightsubnet=0.0.0.0/0
>>rightid=%any
>>type=tunnel
>>auto=route
>>
>
> I started the VPN + the "hides-nl" connection
>
>> Routed Connections:
>>  hide-nl{1}:  ROUTED, TUNNEL, reqid 1
>>  hide-nl{1}:   10.211.55.15/32 === 0.0.0.0/0
>> Security Associations (1 up, 0 connecting):
>>  hide-nl[1]: ESTABLISHED 20 minutes ago,
>> 10.211.55.15[10.211.55.15]...95.211.101.198[C=MY, ST=Wilayah Persekutuan,
>> L=Labuan, O=eVenture Limited, CN=*.hide.me]
>>  hide-nl{2}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: ca4900c6_i
>> cd2bd533_o
>>  hide-nl{2}:   10.3.150.159/32 === 0.0.0.0/0
>
>
> I'm not really sure the VPN is used when I call "curl 172.217.19.68"
> Indeed, I don't see any trace of the "vtixx" interface.I'm sure.
> Moreover, something seems strange in my ipsec.conf - Does it mean the
> filter is only done in the script and each time the interface is created?
>
> Seems I need help and explanations/pointers...
> Thanks / Best Regards,
> Gilles
>
>
> On Thu, May 17, 2018 at 3:16 PM, Phil Frost <p...@postmates.com> wrote:
>
>> One way to go would be configuring a route based VPN[1]. Then you can use
>> all kinds of Linux routing tricks to get just that user's traffic over the
>> VPN by directing it to the vti interface. For example you could launch that
>> user's processes in a network namespace, or use the "owner" module of
>> iptables to match traffic from processes run as that user and mangle them
>> to use the VPN.
>>
>>   [1]: https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
>>
>> On Thu, May 17, 2018 at 9:25 AM Gilles Printemps <gprinte...@gmail.com>
>> wrote:
>>
>>> Hi,
>>> Is there a way to force all the traffic from a specific linux user to be
>>> routed through the VPN?
>>> I would like to use the split tunnelling but I don't understand how to
>>> configure Strongswan?
>>>
>>> Thanks for your help / BR Gilles
>>>
>>
>

Re: [strongSwan] Forcing all traffic from a specific user to use Strongswan

[Phil Frost]

One way to go would be configuring a route based VPN[1]. Then you can use
all kinds of Linux routing tricks to get just that user's traffic over the
VPN by directing it to the vti interface. For example you could launch that
user's processes in a network namespace, or use the "owner" module of
iptables to match traffic from processes run as that user and mangle them
to use the VPN.

  [1]: https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN

On Thu, May 17, 2018 at 9:25 AM Gilles Printemps 
wrote:

> Hi,
> Is there a way to force all the traffic from a specific linux user to be
> routed through the VPN?
> I would like to use the split tunnelling but I don't understand how to
> configure Strongswan?
>
> Thanks for your help / BR Gilles
>

Re: [strongSwan] Authentication against Linux Users

[Phil Frost]

On Tue, May 15, 2018 at 10:00 PM Pete Ashdown  wrote:

> I am trying to get NTLM hashes stored in LDAP to be authenticated via
> eap-radius.  However, when I connect a Windows client (7 or 10), I see this
> type of failure in the freeradius logs:
>
>  radius3 freeradius[23803]: Login Incorrect: [\\300\\250z+/] from
> client vpn01 (mac=, cli=[IP deleted][4500], port=ikev2-mschapv2)
>
> An incorrect login would normally have the form of:
>
>  Login Incorrect: [username/badpassword]
>
> Any idea why Windows (or Strongswan) is sending garbage for the
> username/password?
>

I have seen this, and I'm having a vague recollection! It's not entirely
garbage, it's the client IP in binary, interpreted as a string.

ord("\300") -> 192
ord("\250") -> 168
ord("z") -> 122
ord("+") -> 43

It's been a while, but I'm 65% sure this "garbage username" symptom is what
you'll see if the EAP exchange between Strongswan and FreeRADIUS isn't
working, and the garbage username is a red herring. I'd guess without a
functional EAP exchange the real username is never exchanged, and so what
you're seeing is some fallback.

http://lists.freeradius.org/pipermail/freeradius-users/2018-March/090898.html

Re: [strongSwan] Strongswan VPN with CA

[Phil Frost]

It doesn't appear you've configured strongswan to trust any CAs anywhere.
See /etc/ipsec.d/cacerts, the "CA SECTIONS" section in ipsec.conf(5), and
the leftca and rightca options.

On Wed, May 16, 2018 at 9:40 AM Michal Grzelak 
wrote:

> I have a Site to Site VPN between Strongswan and Cisco working over PSK.
> Wanted to upgrade it to authenticate via Certificates, but can't get it
> done. Receiving following error:
>
>
> May  9 13:57:20 strongswan charon: 13[CFG]   ocsp response correctly signed 
> by "C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root 
> Validation Authority - G2"
>
> May  9 13:57:20 strongswan charon: 13[CFG]   ocsp response is valid: until 
> May 11 01:05:00 2018
>
> May  9 13:57:20 strongswan charon: 13[CFG]   using cached ocsp response
>
> May  9 13:57:20 strongswan charon: 13[CFG] certificate status is good
>
> May  9 13:57:20 strongswan charon: 13[CFG] certificate policy 
> 2.16.840.1.114413.1.7.23.1 for 'OU=Domain Control Validated, 
> CN=hostname.somedomain.com' not allowed by trustchain, ignored
>
> May  9 13:57:20 strongswan charon: 13[CFG] certificate policy 2.23.140.1.2.1 
> for 'OU=Domain Control Validated, CN=hostname.somedomain.com' not allowed by 
> trustchain, ignored
>
> May  9 13:57:20 strongswan charon: 13[CFG]   reached self-signed root ca with 
> a path length of 1
>
> May  9 13:57:20 strongswan charon: 13[IKE] signature validation failed, 
> looking for another key
>
> The Certificates for both ends are signed by two different CA, but already
> exchanged public root and intermediate certs. On cisco side I see the
> tunnel goes up for both Phase 1 and 2, so its good. Strongswan has problem
> with it and no SA is up.
>
> Configuration:
>
> conn testconn
> auto=start
> left=%any
> leftfirewall=yes
> leftid=@strongswan.mydomain.com
> leftid=x.x.x.x
> leftcert=strongswan.mydomain.com.pem
> right=y.y.y.y
> rightid=%any
> rightid=@hostname.somedomain.com
> type=tunnel
> ikelifetime=24h
> keylife=1h
> esp=aes256-sha384-ecp521
> ike=aes256-sha384-modp1024
> keyingtries=%forever
> keyexchange=ikev2
> leftsubnet=z.z.z.z/z
> rightsubnet=u.u.u.u/u
> dpddelay=10s
> dpdtimeout=30s
> dpdaction=restart
>
> What be wrong here? Any suggestions?
> Thanks.
>
>
> --
> Best regards,
> Michał
>
>

Re: [strongSwan] Can't make routing work to pass Internet traffic

[Phil Frost]

On Sat, May 5, 2018 at 2:58 AM Arab Abdulla  wrote:

> Client 1 send the packet addressed for 8.8.4.4, and the server receives
> it. Now the server doesn't know about the routing tables on client 1: it
> only knows it has this packet addressed to 8.8.4.4. How does the server
> know a packet for 8.8.4.4 should go through client 2?
>
>
> It seems it's the root of the problem. Why the server does not know? Why
> gateway is not used? My routing on client 1 is:
> root@ubuntu1604:~# ip r g 8.8.4.4
> 8.8.4.4 via 10.10.3.1 dev ipsec2  src 10.10.2.1
> cache
>
> So, IPSEC should incapsulate its destination and sends traffic to
> 10.10.3.1, is not it? But, instead, on server I see (49 is client 1 and 47
> is server):
>
> 19:38:57.180893 IP 10.2.0.49.4500 > 10.2.0.47.4500: UDP-encap:
> ESP(spi=0xc3d23f24,seq=0xc), length 120
> 19:38:57.180981 IP 10.10.2.1 > 8.8.4.4: ICMP echo request, id 13060, seq
> 12, length 64
>

That's simply not how IP works. Without any special options, the IP header
doesn't contain the path, but only the final destination. Nominally, the
path is determined independently by each router deciding what the next hop
is, and adjacent routers are on the same L2 network (which may be a
point-to-point ethernet link of only two hosts, or in your case, a virtual
one implemented as an IPsec tunnel.)

The canonical solution would be to have a route on the server (10.10.1.1, I
think it was?). Other ideas involve an ipip tunnel between the clients
(10.10.3.1 and 10.10.2.1), or possibly you can do something with IP source
routing options.

Re: [strongSwan] Can't make routing work to pass Internet traffic

[Phil Frost]

On Fri, May 4, 2018 at 7:57 AM Arab Abdulla  wrote:

> Dear Admins!
>
> Please help. Can't make work routing. I have net scheme:
> IPSEC Client 1 <--> IPSEC Server <--> IPSEC Client 2
>
> IPSEC IPs of computers:
> Server: 10.1.1.1
> Client 1: 10.1.2.1
> Client 2: 10.1.3.1
>
> I can ping 10.1.3.1 from 10.1.2.1, traffic goes through 10.1.1.1. It works.
>
> I need to make "Client 2" an Internet gateway to pass all Internet traffic
> from Client 1.
>
> But when I try to add route:
> ip route add 8.8.4.4/32 via 10.1.3.1
> it seems route not working, like gateway 10.1.3.1 is just ignored. Traffic
> ends on 10.1.1.1, and do not pass to 10.1.3.1 at all. I check it with
> tcpdump.
>

Client 1 send the packet addressed for 8.8.4.4, and the server receives it.
Now the server doesn't know about the routing tables on client 1: it only
knows it has this packet addressed to 8.8.4.4. How does the server know a
packet for 8.8.4.4 should go through client 2? You can check the server
routing tables with "ip route get 8.8.4.4", or perhaps "ip route get
8.8.4.4 from 10.1.2.1: what's it say? Does it show the server thinks the
next hop should be 10.1.3.1?

Reverse path filtering is another thing that can be a problem in scenarios
like this, especially if client 1 has some IP address other than 10.1.2.1,
and is not using 10.1.2.1 as the source address for the packets it sends
destined for the internet. the log_martians and rp_filter sysctls are
something to check. I've spent more than a few hours racking my brain as to
why packets are "just disappearing" before remembering reverse path
filtering.

Re: [strongSwan] Cleaning up SAs

[Phil Frost]

Does dpdaction=clear do what you need?

On Fri, Apr 27, 2018, 10:11 rajeev nohria  wrote:

> I am using Strongswan5.5.0 and using Davici interface. Is there way (any
> options) to delete the SA immediately if peer goes down instead of  going
> through retries?
>
> Any help is appreciated. I could not find anything so far..
>
> Thanks,
> Rajeev
>