date:20180313

Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

2018-03-13 Thread Shuchen He

Hi Andreas,

Thanks for the help. Please see the command result.

# ip route list table 220
10.2.1.0/24 via 10.168.60.226 dev usb0  proto static  src 192.168.199.100

Cheers

George

From: Andreas Steffen 
Sent: Tuesday, 13 March 2018 7:36 PM
To: Shuchen He; users@lists.strongswan.org
Subject: Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

Hi,

I don't see the virtual IP address 10.2.1.211/32 installed on your
physical USB interface with IP address 10.39.63.211. Does the command

  ip route list table 220

show any source route entries?

Regards

Andreas

On 12.03.2018 11:45, Shuchen He wrote:
> Hi,
>
> I have setup a VPN between ASA and strongswan using IKE1. The strongswan
> work as remote VPN using PSK XAuth.
>
> The VPN tunnel is up but I can not ping the remote site. Below is the
> configuration and some output.
>
> My observation at the moment is that the Linux kernel has setup
> everything but the TS traffic just does not leave the Linux box.  When I
> ping remote site, I can see "ip xfrm state" actually shows a flow for my
> traffic... but the flow is somehow dropped by either the kernel or
> strongswan.
>
>  Can you please let me know what else I should do to further
> troubleshoot the issue?
>
> *Configuration
> *
> connections {
> home {
> aggressive = yes
> dpd_delay = 30
> dpd_timeout = 90
> version = 1
> remote_addrs = 126.2.1.4
> # uncomment if the responder only supports crappy crypto. But
> seriously,
> # every single one of those algorithms is broken. Better spend
> some $$$
> # on a better solution.
> proposals = aes256-sha1-modp1024
> vips = 0.0.0.0,::
> local-1 {
> auth = psk
> id = acompanyTest
> }
> local-2 {
> auth = xauth-generic
> xauth_id = acompanyTest
> }
> remote-1 {
> auth = psk
> # You might have to set this to the correct value, if the
> responder isn't configure correctly.
> #id = 126.2.1.4
> }
> children {
> home {
> remote_ts = 10.2.1.0/24
> #local_ts=192.168.199.0/24,0.0.0.0
> # uncomment if the responder only supports crappy
> crypto. But seriously,
> # every single one of those algorithms is broken. Better
> spend some $$$
> # on a better solution.
> # esp_proposals = 3des-md5!
> # Use this, if you want PFS with DH group 2.
> # esp_proposals = 3des-md5-modp1024!
> esp_proposals = aes128-sha1-modp768
> }
> }
>}
> }
> secrets {
> ike-home {
> id = 126.2.1.4
> secret = "acompany123"
> }
> eap-home {
> id = acompanyTest
> secret = "acompany123"
> }
> }
>
> # ipsec statusall
> Status of IKE charon daemon (strongSwan 5.6.2, Linux
> 3.0.35-2666-gbdde708-g889281e-dirty, armv7l):
>   uptime: 18 minutes, since Mar 12 18:15:45 2018
>   malloc: sbrk 253952, mmap 0, used 158560, free 95392
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 6
>   loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce
> x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey
> sshkey pem fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink
> resolve socket-default stroke vici updown xauth-generic counters
> Listening IP addresses:
>   192.168.199.100
>   192.168.199.254
>   192.168.199.141
>   192.168.126.1
>   10.39.63.211
> Connections:
> site:  %any...126.2.1.4  IKEv1
> site:   local:  [mylocalsite] uses pre-shared key authentication
> site:   remote: uses pre-shared key authentication
> site:   child:  192.168.199.0/24 === 10.2.1.0/24 TUNNEL
> home:  %any...126.2.1.4  IKEv1 Aggressive, dpddelay=30s
> home:   local:  [acompanyTest] uses pre-shared key authentication
> home:   local:  uses XAuth authentication: generic with XAuth
> identity 'acompanyTest'
> home:   remote: uses pre-shared key authentication
> home:   child:  dynamic === 10.2.1.0/24 TUNNEL, dpdaction=clear
> Routed Connections:
> site{1}:  ROUTED, TUNNEL, reqid 1
> site{1}:   192.168.199.0/24 === 10.2.1.0/24
> Security Associations (1 up, 0 connecting):
> home[1]: ESTABLISHED 17 minutes ago,
> 10.39.63.211[acompanyTest]...126.2.1.4[126.2.1.4]
> home[1]: IKEv1 SPIs: 504550d01ee905e2_i* 2311e0ae0c6c454f_r,
> rekeying in 3 hours
> home[1]: IKE proposal:
> AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
> home{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs:
> cc621d5e_i 3545bd6a_o
> home{2}:  AES_CBC_128/HMAC_SHA1_96/MODP_768, 0 bytes_i, 0
> bytes_o, rekeying in 40 minutes
> home{2}:   10.2.1.211/32 === 10.2.1.0/24

Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

2018-03-13 Thread Shuchen He

Hi Noel,

Thank you for the update. Please see below output. Yes, I understand the DH 
group is better to be 5, thanks for the reminder.

iptables-save -c
# Generated by iptables-save v1.6.2 on Wed Mar 14 07:34:57 2018
*raw
:PREROUTING ACCEPT [1610:117869]
:OUTPUT ACCEPT [2109:892186]
COMMIT
# Completed on Wed Mar 14 07:34:57 2018
# Generated by iptables-save v1.6.2 on Wed Mar 14 07:34:57 2018
*nat
:PREROUTING ACCEPT [32:14382]
:INPUT ACCEPT [32:14382]
:OUTPUT ACCEPT [31:2493]
:POSTROUTING ACCEPT [5:208]
[26:2285] -A POSTROUTING -o usb0 -j MASQUERADE
COMMIT
# Completed on Wed Mar 14 07:34:57 2018
# Generated by iptables-save v1.6.2 on Wed Mar 14 07:34:57 2018
*mangle
:PREROUTING ACCEPT [1611:117909]
:INPUT ACCEPT [1611:117909]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2117:893322]
:POSTROUTING ACCEPT [2121:893390]
COMMIT
# Completed on Wed Mar 14 07:34:57 2018
# Generated by iptables-save v1.6.2 on Wed Mar 14 07:34:57 2018
*filter
:INPUT ACCEPT [1612:117949]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2120:893774]
[0:0] -A FORWARD -i eth0 -j ACCEPT
[0:0] -A FORWARD -i wlan0 -j ACCEPT
COMMIT
# Completed on Wed Mar 14 07:34:57 2018
# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 50:ff:99:30:13:10 brd ff:ff:ff:ff:ff:ff
inet 192.168.199.100/24 brd 192.168.199.255 scope global eth0
inet 192.168.199.254/24 brd 192.168.199.254 scope global secondary eth0
inet6 fe80::52ff:99ff:fe30:1310/64 scope link
  valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc pfifo_fast state 
DOWN qlen 1000
link/ether 50:ff:99:30:13:11 brd ff:ff:ff:ff:ff:ff
4: tunl0:  mtu 1480 qdisc noop state DOWN
link/ipip 0.0.0.0 brd 0.0.0.0
5: sit0:  mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
6: ip6tnl0:  mtu 1452 qdisc noop state DOWN
link/tunnel6 :: brd ::
7: wlan0:  mtu 1500 qdisc mq state UP qlen 1000
link/ether 08:ea:40:72:28:b7 brd ff:ff:ff:ff:ff:ff
inet 192.168.126.1/24 brd 192.168.126.255 scope global wlan0
inet6 fe80::aea:40ff:fe72:28b7/64 scope link
   valid_lft forever preferred_lft forever
8: usb0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:1e:10:1f:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.168.60.225/30 brd 10.168.60.227 scope global usb0
inet 10.2.1.213/32 scope global usb0
inet6 fe80::1e:10ff:fe1f:0/64 scope link
   valid_lft forever preferred_lft forever
# ip r show table all
10.2.1.0/24 via 10.168.60.226 dev usb0  table 220  proto static  src 
192.168.199.100
default via 10.168.60.226 dev usb0
10.168.60.224/30 dev usb0  proto kernel  scope link  src 10.168.60.225
192.168.126.0/24 dev wlan0  proto kernel  scope link  src 192.168.126.1
192.168.199.0/24 dev eth0  proto kernel  scope link  src 192.168.199.100
local 10.2.1.213 dev usb0  table local  proto kernel  scope host src 10.2.1.213
broadcast 10.168.60.224 dev usb0  table local  proto kernel  scope link  src 
10.168.60.225
local 10.168.60.225 dev usb0  table local  proto kernel  scope host  src 
10.168.60.225
broadcast 10.168.60.227 dev usb0  table local  proto kernel  scope link  src 
10.168.60.225
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link src 127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 
127.0.0.1
broadcast 192.168.126.0 dev wlan0  table local  proto kernel  scope link  src 
192.168.126.1
local 192.168.126.1 dev wlan0  table local  proto kernel  scope host  src 
192.168.126.1
broadcast 192.168.126.255 dev wlan0  table local  proto kernel  scope link  src 
192.168.126.1
broadcast 192.168.199.0 dev eth0  table local  proto kernel  scope link  src 
192.168.199.100
local 192.168.199.100 dev eth0  table local  proto kernel  scope host  src 
192.168.199.100
local 192.168.199.254 dev eth0  table local  proto kernel  scope host  src 
192.168.199.100
broadcast 192.168.199.254 dev eth0  table local  proto kernel  scope link  src 
192.168.199.100
broadcast 192.168.199.255 dev eth0  table local  proto kernel  scope link  src 
192.168.199.100
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  
error -101 hoplimit 255
fe80::/64 dev wlan0  proto kernel  metric 256
fe80::/64 dev eth0  proto kernel  metric 256
fe80::/64 dev usb0  proto kernel  metric 256
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  
error -101 hoplimit 255
local ::1 via :: dev lo  table local  proto none  metric 0
local fe80:: via :: dev lo  table local  proto none  metric 0
local fe80:: via :: dev lo  table local  proto none  metric 0
local fe80:: via :: dev lo  table local  proto none  metric 0
local fe80::1e:10ff:fe1f:0

Re: [strongSwan] StrongSwan - can't route traffic over it

2018-03-13 Thread Brenden

As in this?

# sudo iptables -A FORWARD --match policy --pol ipsec --dir in  --proto esp
-s 10.4.34.70/32 -j ACCEPT
 # sudo iptables -A FORWARD --match policy --pol ipsec --dir out --proto
esp -d 10.4.34.70/32 -j ACCEPT


On 13 March 2018 at 23:22, Noel Kuntze <
noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:

> You need to accepts ESP packets in *filter INPUT (-p esp).
>
> On 12.03.2018 06:01, Brenden wrote:
> > I'm guessing my NAT rules may be messed up, any ideas what might be
> wrong?
> >
> >
> > # iptables-save
> > # Generated by iptables-save v1.6.0 on Mon Mar 12 14:22:04 2018
> > *nat
> > :PREROUTING ACCEPT [14:1916]
> > :INPUT ACCEPT [14:1916]
> > :OUTPUT ACCEPT [37:2220]
> > :POSTROUTING ACCEPT [18:1080]
> > -A POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT
> > -A POSTROUTING -s 1.2.3.112/24  -o ens33 -m policy
> --dir out --pol ipsec -j ACCEPT
> > -A POSTROUTING -s 1.2.3.112/24  -o ens33 -j
> MASQUERADE
> > -A POSTROUTING -s 1.2.3.112/24  -o ens33 -m policy
> --dir out --pol ipsec -j ACCEPT
> > -A POSTROUTING -s 1.2.3.112/24  -o ens33 -j
> MASQUERADE
> > COMMIT
> > # Completed on Mon Mar 12 14:22:04 2018
> > # Generated by iptables-save v1.6.0 on Mon Mar 12 14:22:04 2018
> > *filter
> > :INPUT ACCEPT [74:14670]
> > :FORWARD ACCEPT [0:0]
> > :OUTPUT ACCEPT [215:33304]
> > -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> > -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
> > -A INPUT -i lo -j ACCEPT
> > -A INPUT -p udp -m udp --dport 500 -j ACCEPT
> > -A INPUT -p udp -m udp --dport 4500 -j ACCEPT
> > -A FORWARD -s 1.2.3.112/24  -m policy --dir in
> --pol ipsec --proto esp -j ACCEPT
> > -A FORWARD -d 1.2.3.112/24  -m policy --dir out
> --pol ipsec --proto esp -j ACCEPT
> > -A FORWARD -s 1.2.3.112/24  -m policy --dir in
> --pol ipsec --proto esp -j ACCEPT
> > -A FORWARD -d 1.2.3.112/24  -m policy --dir out
> --pol ipsec --proto esp -j ACCEPT
> > COMMIT
> > # Completed on Mon Mar 12 14:22:04 2018
> >
> >
> > On 8 March 2018 at 20:34, Noel Kuntze  ml@thermi.consulting  consulting>> wrote:
> >
> > Hi,
> >
> > Your iptables rules in the *nat table probably cause your issue.
> >
> > Take a look at the article about forwarding and split tunneling[1].
> And stop using `iptables -L`, it doesn't show you everything. Always use
> `iptables-save` or `iptables-save -c` instead.
> >
> > Kind regards
> >
> > Noel
> >
> > [1] https://wiki.strongswan.org/projects/strongswan/wiki/
> ForwardingAndSplitTunneling#General-NAT-problems <
> https://wiki.strongswan.org/projects/strongswan/wiki/
> ForwardingAndSplitTunneling#General-NAT-problems>
> >
> > On 07.03.2018 05:37, Brenden wrote:
> > > Hi All,
> > >
> > > I'm attempting to run StrongSwan on Ubuntu 16.04.3 LTS.
> > >
> > > IPs chanaged for privacy:
> > >
> > > My server IP 110.0.0.110
> > > My subnet is 110.0.0.0/25 
> > > Internal IP: 192.168.50.214
> > > Remote Peers: 1.2.3.111 (pri) / 1.2.3.112 (sec)
> > >
> > > The primary connection is currently not configured (its still
> running on
> > > our hardware FW) but the secondary one has been re-configured with
> the
> > > other peer and connection successfully establishes.
> > >
> > > They can see our successful connection is up but can't see any
> traffic
> > > being sent from our side.
> > >
> > > I am running HAPROXY on my strongswans server which forwards
> traffic from
> > > 192.168.50.214:  to
> 10.4.34.70:  (via IPSEC tunnel). I can't ping,
> > > telnet, curl or do anything against this host.
> > >
> > > I have this working in a legacy (undocumented environment on a
> Fortigate
> > > FW), but that's being replaced.
> > >
> > > # ipsec statusall
> > > Status of IKE charon daemon (strongSwan 5.3.5, Linux
> 4.4.0-109-generic,
> > > x86_64):
> > >   uptime: 51 minutes, since Mar 07 13:21:13 2018
> > >   malloc: sbrk 2588672, mmap 0, used 588944, free 1999728
> > >   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue:
> 0/0/0/0,
> > > scheduled: 7
> > >   loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5
> random
> > > nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12
> pgp
> > > dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr
> > > kernel-netlink resolve socket-default connmark farp stroke updown
> > > eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2
> > > eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2
> > > eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc
> xauth-generic
> > > xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 t

Re: [strongSwan] Site to site VPN initiated from a NAT router

2018-03-13 Thread Zachary Cutlip

I think I got it working. 

I’m not sure if there is a better way, or if this is perhaps the canonical way 
of doing it, but here’s what I did. Please let me know if this isn’t the normal 
way to accomplish this.

I had assumed traffic from the wifi clients (10.88.88.0) needed to be sent to 
the MASQUERADE target on the VPN client so they could be rewritten to appear as 
if they originated from that host before being tunneled. What I ended up doing 
is instead adding the 10.88.88.0/24 network to the VPN client’s leftsubnet and 
the remote server’s rightsubne, allowing those packets to be tunneled as-is. I 
also added forwarding and masquerading iptables rules on the server so that the 
10.88.88.0 packets could be properly masqueraded on that end.

When the ipsec connection is brought down, NAT masquerading automatically 
resumes on the local box, and it behaves like an ordinary NAT router. That’s a 
nice bonus because I’ll need to authenticate through some networks’ captive 
portals before the ipsec connection can be established.

Happy to post configs for anyone who’s interested.




> On Mar 13, 2018, at 6:59 AM, Noel Kuntze 
>  wrote:
> 
> You should stop looking at `iptables -L` and use `iptables-save` instead. It 
> is a much better tool for it, in any regard.
> 
> Please provide the output of `ipsec statusall`, `iptables-save -c`, `ip a`, 
> `ip r show table all` and `ip ru`.
> 
> Kind regards
> 
> Noel
> 
> On 13.03.2018 08:41, Zachary Cutlip wrote:
>> I’ve tweaked my iptables rules, and now traffic from the strongswan client 
>> box gets routed through the tunnel as expected. Also wifi client 
>> (10.88.88.0) traffic now gets routed, where it wasn’t before. However, that 
>> traffic still isn’t going through the tunnel.
>> 
>> Here are the iptables rules when the ipsec connection is established:
>> 
>> $ sudo iptables -L
>> Chain INPUT (policy ACCEPT)
>> target prot opt source   destination
>> ACCEPT all  --  anywhere 10.19.48.2   policy match 
>> dir in pol ipsec reqid 1 proto esp
>> 
>> Chain FORWARD (policy ACCEPT)
>> target prot opt source   destination
>> ACCEPT all  --  anywhere 10.19.48.2   policy match 
>> dir in pol ipsec reqid 1 proto esp
>> ACCEPT all  --  10.19.48.2   anywhere policy match 
>> dir out pol ipsec reqid 1 proto esp
>> 
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source   destination
>> ACCEPT all  --  10.19.48.2   anywhere policy match 
>> dir out pol ipsec reqid 1 proto esp
>> 
>> $ sudo iptables -t nat -L
>> Chain PREROUTING (policy ACCEPT)
>> target prot opt source   destination
>> 
>> Chain INPUT (policy ACCEPT)
>> target prot opt source   destination
>> 
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source   destination
>> 
>> Chain POSTROUTING (policy ACCEPT)
>> target prot opt source   destination
>> ACCEPT all  --  10.88.88.0/24anywhere policy match 
>> dir out pol ipsec
>> MASQUERADE  all  --  10.88.88.0/24anywhere
>> 
>> 
>>> On Mar 12, 2018, at 7:36 PM, Zachary Cutlip  wrote:
>>> 
>>> Hello,
>>> 
>>> I’m trying to set up an IPSec VPN that’s a little different from most 
>>> projects I’ve seen documented.
>>> 
>>> I’m building a NAT router on Debian that I plan to travel with. I guess you 
>>> might say my strongswan use case is sort of a hybrid between road warrior & 
>>> site-to-site.
>>> 
>>> I’m confused on how to set up ipsec.conf and iptables such that all wifi 
>>> clients on connecting to the NAT router/WiFi AP get their traffic routed 
>>> over the tunnel.
>>> 
>>> Here are some details:
>>> 
>>> The Debian box has two interfaces
>>> - wan0, internet facing, configured via DHCP via whatever network its 
>>> connected to
>>> - lan0, WiFi interface in AP mode with hostapd, 10.88.88.1/24, 
>>> (There is also a third interface for management: eth0:10.99.99.1)
>>> 
>>> dnsmasq gives out DHCP configuration to wifi clients over lan0.
>>> 
>>> I’m connecting to a strongswan instance hosted on digital ocean with a 
>>> fixed IP address.
>>> 
>>> When I take the box out of NAT router mode by flushing IPtables, I can 
>>> initiate a connection to the remote instance, and traffic originating from 
>>> the Debian box seems to go over the tunnel as expected. If I have iptables 
>>> set up to do NAT routing, and then initiate the VPN connection, two things 
>>> happen:
>>> 1. Traffic from the Debian box (such as traceroute 8.8.8.8) is no longer 
>>> routed over the tunnel.
>>> 2. Traffic from the wifi clients doesn’t get routed at all.
>>> 
>>> I feel like this should be pretty straightforward; I’m just missing 
>>> something. Any advice?
>>> 
>>> Here’s what my iptables looks like when the NAT router is working, and 
>>> there are no ipsec connections:
>>> 
>>> sudo iptables -L
>>> Chain INPUT (policy ACCEPT)
>>> target

Re: [strongSwan] No CHILD_SA tunnel{2} established with nat public IP

2018-03-13 Thread Info

No one is using swanctl yet?


On 03/13/2018 06:09 AM, Sujoy wrote:
> Hi All,
>  
>   I am facing a issue while establish tunnel through the nated Public
> IP. When I connect to the same Strongswan server from LAN I get
> "*CHILD_SA tunnel{2} established with SPIs cb7bd615_i c3fb87d7_o and
> TS 172.25.12.38/32 == 172.25.1.23/32"*. But from public network
> "IKE_SA tunnel is established but CHILD_SA tunnel" is not displayed.
> Even during the public IP tunneling- "ip route list table 220" no
> output in the server. Due to that traffic is also not passing.
> The configuration file is same of both the client. It will be a big
> help if someone can provide any solution.
>
>
> root@Device_BD2009:~# ipsec up tunnel
> no files found matching '/etc/strongswan.d/*.conf'
> initiating IKE_SA tunnel[1] to X.X.X.X
> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
> N(FRAG_SUP) N(HASH_ALG) ]
> sending packet: from 192.168.1.100[500] to X.X.X.X[500] (1080 bytes)
> received packet: from X.X.X.X[500] to 192.168.1.100[500] (464 bytes)
> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
> N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
> local host is behind NAT, sending keep alives
> remote host is behind NAT
> authentication of '192.168.1.100' (myself) with pre-shared key
> establishing CHILD_SA tunnel
> generating IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH)
> N(EAP_ONLY) ]
> sending packet: from 192.168.1.100[4500] to X.X.X.X[4500] (332 bytes)
> received packet: from X.X.X.X[4500] to 192.168.1.100[4500] (220 bytes)
> parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) ]
> authentication of 'X.X.X.X' with pre-shared key successful
> IKE_SA tunnel[1] established between
> 192.168.1.100[192.168.1.100]...X.X.X.X[X.X.X.X]
> scheduling reauthentication in 10015s
> maximum IKE_SA lifetime 10555s
> connection 'tunnel' established successfully
>
>
> config setup
>
>     charondebug="all"
>     uniqueids=no
>     strictcrlpolicy=no
> conn %default
> conn tunnel #
>    left=192.168.1.100
>    leftsubnet=192.168.1.100/32
>    right=X.X.X.X
>    rightsubnet=X.X.X.X/32
>    ike=aes256-sha1-modp2048
>    esp=aes256-sha1
>    keyingtries=1
>    keylife=60m
>    dpddelay=30s
>    dpdtimeout=150s
>    dpdaction=clear
>    authby=psk
>    auto=route
>    keyexchange=ikev2
>    type=tunnel
>    mobike=no
>    fragmentation=yes
>
> -- 
> Thanks in advance.

Re: [strongSwan] Site to site VPN initiated from a NAT router

2018-03-13 Thread Noel Kuntze

You should stop looking at `iptables -L` and use `iptables-save` instead. It is 
a much better tool for it, in any regard.

Please provide the output of `ipsec statusall`, `iptables-save -c`, `ip a`, `ip 
r show table all` and `ip ru`.

Kind regards

Noel

On 13.03.2018 08:41, Zachary Cutlip wrote:
> I’ve tweaked my iptables rules, and now traffic from the strongswan client 
> box gets routed through the tunnel as expected. Also wifi client (10.88.88.0) 
> traffic now gets routed, where it wasn’t before. However, that traffic still 
> isn’t going through the tunnel.
>
> Here are the iptables rules when the ipsec connection is established:
>
> $ sudo iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  anywhere 10.19.48.2   policy match 
> dir in pol ipsec reqid 1 proto esp
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  anywhere 10.19.48.2   policy match 
> dir in pol ipsec reqid 1 proto esp
> ACCEPT all  --  10.19.48.2   anywhere policy match 
> dir out pol ipsec reqid 1 proto esp
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  10.19.48.2   anywhere policy match 
> dir out pol ipsec reqid 1 proto esp
>
> $ sudo iptables -t nat -L
> Chain PREROUTING (policy ACCEPT)
> target prot opt source   destination
>
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
>
> Chain POSTROUTING (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  10.88.88.0/24anywhere policy match 
> dir out pol ipsec
> MASQUERADE  all  --  10.88.88.0/24anywhere
>
>
>> On Mar 12, 2018, at 7:36 PM, Zachary Cutlip  wrote:
>>
>> Hello,
>>
>> I’m trying to set up an IPSec VPN that’s a little different from most 
>> projects I’ve seen documented.
>>
>> I’m building a NAT router on Debian that I plan to travel with. I guess you 
>> might say my strongswan use case is sort of a hybrid between road warrior & 
>> site-to-site.
>>
>> I’m confused on how to set up ipsec.conf and iptables such that all wifi 
>> clients on connecting to the NAT router/WiFi AP get their traffic routed 
>> over the tunnel.
>>
>> Here are some details:
>>
>> The Debian box has two interfaces
>> - wan0, internet facing, configured via DHCP via whatever network its 
>> connected to
>> - lan0, WiFi interface in AP mode with hostapd, 10.88.88.1/24, 
>> (There is also a third interface for management: eth0:10.99.99.1)
>>
>> dnsmasq gives out DHCP configuration to wifi clients over lan0.
>>
>> I’m connecting to a strongswan instance hosted on digital ocean with a fixed 
>> IP address.
>>
>> When I take the box out of NAT router mode by flushing IPtables, I can 
>> initiate a connection to the remote instance, and traffic originating from 
>> the Debian box seems to go over the tunnel as expected. If I have iptables 
>> set up to do NAT routing, and then initiate the VPN connection, two things 
>> happen:
>> 1. Traffic from the Debian box (such as traceroute 8.8.8.8) is no longer 
>> routed over the tunnel.
>> 2. Traffic from the wifi clients doesn’t get routed at all.
>>
>> I feel like this should be pretty straightforward; I’m just missing 
>> something. Any advice?
>>
>> Here’s what my iptables looks like when the NAT router is working, and there 
>> are no ipsec connections:
>>
>> sudo iptables -L
>> Chain INPUT (policy ACCEPT)
>> target prot opt source   destination
>>
>> Chain FORWARD (policy ACCEPT)
>> target prot opt source   destination
>> ACCEPT all  --  anywhere anywhere ctstate 
>> RELATED,ESTABLISHED
>> ACCEPT all  --  anywhere anywhere
>>
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source   destination
>>
>> $ sudo iptables -t nat -L
>> Chain PREROUTING (policy ACCEPT)
>> target prot opt source   destination
>>
>> Chain INPUT (policy ACCEPT)
>> target prot opt source   destination
>>
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source   destination
>>
>> Chain POSTROUTING (policy ACCEPT)
>> target prot opt source   destination
>> MASQUERADE  all  --  anywhere anywhere
>>
>> Here’s the ipsec.conf generated by Trail of Bits’s AlgoVPN (I added the 
>> passthroughs):
>>
>> $ cat ipsec.conf
>> conn ikev2-165.x.x.x
>>fragmentation=yes
>>rekey=no
>>dpdaction=clear
>>keyexchange=ikev2
>>compress=no
>>dpddelay=35s
>>
>>
>> ike=aes128gcm16-prfsha512-ecp256,aes128-sha2_512-prfsha512-ecp256,aes128-sha2_384-prfsha384-ecp256!
>>esp=aes128gcm16-ecp256,aes128-sha2_512-prfsha512-ecp256!
>>
>>right=

Re: [strongSwan] ipsec tunnel throughput measurement

2018-03-13 Thread Noel Kuntze

Hi,

That is not really surprising, considering the overhead the block cipher, hmac 
and additional headers contribute.
If your CPU isn't maxed out yet, you can get even higher speeds. You need one 
CHILD_SA per CPU core to take advantage of them.

Kind regards

Noel

On 12.03.2018 17:14, Marco Berizzi wrote:
> Hello everyone,
>
> I have completed some speed test between two slackware linux
> 4.14 system running strongswan. The purpose is to estimate
> the network throughput inside an ipsec tunnel. Strongswan will
> not affect results, but I hope this message will be still
> informative for users subscribed to this list.
>
> Here is the network schema:
>
> ++ ++  ++
> | linux  | | linux  |  | linux  |
> | iperf  +-+ ipsec  +---ipsec tunnel---+ ipsec  +---dummy0 interface
> | client | | gateway|  | gateway|   linux iperf server
> ++ ++  ++
>
> MTU=1500bytes for all systems
> The two ipsec gateway are running on Intel i5-3470@3.20GHz
> AES-NI extension are enabled on this processor and the
> kernel is built with them enabled as externals modules.
> NIC models on the ipsec gateways are Intel Corporation I350
> and Intel Corporation 82579LM
>
> The following esp configuration where tested:
>
> aes256-sha384-modp4096
> camellia256-sha384-modp4096
> camellia128-sha384-modp4096
> chacha20poly1305-ntru256
> 3des-sha384
>
> with the following tcp mss: 200 bytes, 500 bytes, 1000 bytes
> and the maximum permitted by the ipsec tunnel.
>
> And here are the results. Summary: chacha20 is the winner
> followed by aes256 and camellia128.
>
> maximum MSS:
>
> throughput without any tunnel ipsec (only routing):
> 0.00-10.00  sec  1.09 GBytes   933 Mbits/secsender
> 0.00-10.04  sec  1.09 GBytes   929 Mbits/secreceiver
>
> chacha20poly1305
> 0.00-10.00  sec  1.06 GBytes   908 Mbits/secsender
> 0.00-10.05  sec  1.05 GBytes   901 Mbits/secreceiver
>
> aes256-sha384
> 0.00-10.00  sec  1.04 GBytes   896 Mbits/secsender
> 0.00-10.05  sec  1.04 GBytes   889 Mbits/secreceiver
>
> camellia128-sha384
> 0.00-10.00  sec   949 MBytes   796 Mbits/secsender
> 0.00-10.04  sec   947 MBytes   791 Mbits/secreceiver
>
> camellia256-sha384
> 0.00-10.00  sec   805 MBytes   676 Mbits/secsender
> 0.00-10.05  sec   804 MBytes   671 Mbits/secreceiver
>
> 3des-sha384
> 0.00-10.00  sec   280 MBytes   235 Mbits/secsender
> 0.00-10.05  sec   279 MBytes   233 Mbits/secreceiver
>
>
> 1000 bytes MSS:
>
> throughput without any tunnel ipsec (only routing):
> 0.00-10.00  sec  1.06 GBytes   912 Mbits/secsender
> 0.00-10.04  sec  1.06 GBytes   907 Mbits/secreceiver
>
> chacha20poly1305
> 0.00-10.00  sec  1.02 GBytes   874 Mbits/secsender
> 0.00-10.05  sec  1.01 GBytes   867 Mbits/secreceiver
>
> aes256-sha384
> 0.00-10.00  sec  1016 MBytes   852 Mbits/secsender
> 0.00-10.05  sec  1013 MBytes   846 Mbits/secreceiver
>
> camellia128-sha384
> 0.00-10.00  sec   861 MBytes   723 Mbits/secsender
> 0.00-10.04  sec   859 MBytes   718 Mbits/secreceiver
>
> camellia256-sha384
> 0.00-10.00  sec   735 MBytes   617 Mbits/secsender
> 0.00-10.04  sec   733 MBytes   612 Mbits/secreceiver
>
> 3des-sha384
> 0.00-10.00  sec   264 MBytes   221 Mbits/secsender
> 0.00-10.05  sec   262 MBytes   219 Mbits/secreceiver
>
>
> 500 bytes MSS:
>
> throughput without any tunnel ipsec (only routing):
> 0.00-10.00  sec   992 MBytes   832 Mbits/secsender
> 0.00-10.04  sec   990 MBytes   827 Mbits/secreceiver
>
> chacha20poly1305
> 0.00-10.00  sec   920 MBytes   772 Mbits/secsender
> 0.00-10.05  sec   918 MBytes   766 Mbits/secreceiver
>
> aes256-sha384
> 0.00-10.00  sec   879 MBytes   738 Mbits/secsender
> 0.00-10.04  sec   877 MBytes   732 Mbits/secreceiver
>
> camellia128-sha384
> 0.00-10.00  sec   684 MBytes   574 Mbits/secsender
> 0.00-10.04  sec   681 MBytes   569 Mbits/secreceiver
>
> camellia256-sha384
> 0.00-10.00  sec   593 MBytes   498 Mbits/secsender
> 0.00-10.04  sec   591 MBytes   493 Mbits/secreceiver
>
> 3des-sha384
> 0.00-10.00  sec   231 MBytes   194 Mbits/secsender
> 0.00-10.05  sec   229 MBytes   191 Mbits/secreceiver
>
>
> 200 bytes MSS:
>
> throughput without any tunnel ipsec (only routing):
> 0.00-10.00  sec   795 MBytes   667 Mbits/secsender
> 0.00-10.04  sec   792 MBytes   662 Mbits/secreceiver
>
> chacha20poly1305
> 0.00-10.00  sec   549 MBytes   460 Mbits/secsender
> 0.00-10.04  sec   546 MBytes   456 Mbits/secreceiver
>
> aes256-sha384
> 0.00-10.00  sec   499 MBytes

Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

2018-03-13 Thread Noel Kuntze

Hi,

Please provide the outputs of `iptables-save -c`, `ip a`, `ip r show table all` 
and `ip ru`.
Btw, modp768 is considered broken, same for 1024.

Kind regards

Noel

On 12.03.2018 11:45, Shuchen He wrote:
> Hi,
>
> I have setup a VPN between ASA and strongswan using IKE1. The strongswan work 
> as remote VPN using PSK XAuth.
>
> The VPN tunnel is up but I can not ping the remote site. Below is the 
> configuration and some output.
>
> My observation at the moment is that the Linux kernel has setup everything 
> but the TS traffic just does not leave the Linux box.  When I ping remote 
> site, I can see "ip xfrm state" actually shows a flow for my traffic... but 
> the flow is somehow dropped by either the kernel or strongswan.
>
>  Can you please let me know what else I should do to further troubleshoot the 
> issue?
>
> *Configuration
> *
> connections {
>     home {
>     aggressive = yes
>     dpd_delay = 30
>     dpd_timeout = 90
>     version = 1
>     remote_addrs = 126.2.1.4
>     # uncomment if the responder only supports crappy crypto. But 
> seriously,
>     # every single one of those algorithms is broken. Better spend some 
> $$$
>     # on a better solution.
>     proposals = aes256-sha1-modp1024
>     vips = 0.0.0.0,::
>     local-1 {
>     auth = psk
>     id = acompanyTest
>     }
>     local-2 {
>     auth = xauth-generic
>     xauth_id = acompanyTest
>     }
>     remote-1 {
>     auth = psk
>     # You might have to set this to the correct value, if the 
> responder isn't configure correctly.
>     #id = 126.2.1.4
>     }
>     children {
>     home {
>     remote_ts = 10.2.1.0/24
>         #local_ts=192.168.199.0/24,0.0.0.0
>     # uncomment if the responder only supports crappy crypto. But 
> seriously,
>     # every single one of those algorithms is broken. Better 
> spend some $$$
>     # on a better solution.
>     # esp_proposals = 3des-md5!
>     # Use this, if you want PFS with DH group 2.
>     # esp_proposals = 3des-md5-modp1024!
>         esp_proposals = aes128-sha1-modp768
>     }
>     }
>    }
> }
>     secrets {
>     ike-home {
>     id = 126.2.1.4
>     secret = "acompany123"
>     }
>     eap-home {
>     id = acompanyTest
>     secret = "acompany123"
>     }
>     }
>
> # ipsec statusall
> Status of IKE charon daemon (strongSwan 5.6.2, Linux 
> 3.0.35-2666-gbdde708-g889281e-dirty, armv7l):
>   uptime: 18 minutes, since Mar 12 18:15:45 2018
>   malloc: sbrk 253952, mmap 0, used 158560, free 95392
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, 
> scheduled: 6
>   loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 
> revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem 
> fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink resolve 
> socket-default stroke vici updown xauth-generic counters
> Listening IP addresses:
>   192.168.199.100
>   192.168.199.254
>   192.168.199.141
>   192.168.126.1
>   10.39.63.211
> Connections:
>     site:  %any...126.2.1.4  IKEv1
>     site:   local:  [mylocalsite] uses pre-shared key authentication
>     site:   remote: uses pre-shared key authentication
>     site:   child:  192.168.199.0/24 === 10.2.1.0/24 TUNNEL
>     home:  %any...126.2.1.4  IKEv1 Aggressive, dpddelay=30s
>     home:   local:  [acompanyTest] uses pre-shared key authentication
>     home:   local:  uses XAuth authentication: generic with XAuth 
> identity 'acompanyTest'
>     home:   remote: uses pre-shared key authentication
>     home:   child:  dynamic === 10.2.1.0/24 TUNNEL, dpdaction=clear
> Routed Connections:
>     site{1}:  ROUTED, TUNNEL, reqid 1
>     site{1}:   192.168.199.0/24 === 10.2.1.0/24
> Security Associations (1 up, 0 connecting):
>     home[1]: ESTABLISHED 17 minutes ago, 
> 10.39.63.211[acompanyTest]...126.2.1.4[126.2.1.4]
>     home[1]: IKEv1 SPIs: 504550d01ee905e2_i* 2311e0ae0c6c454f_r, rekeying 
> in 3 hours
>     home[1]: IKE proposal: 
> AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>     home{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cc621d5e_i 
> 3545bd6a_o
>     home{2}:  AES_CBC_128/HMAC_SHA1_96/MODP_768, 0 bytes_i, 0 bytes_o, 
> rekeying in 40 minutes
>     home{2}:   10.2.1.211/32 === 10.2.1.0/24
> root@wheezy-armel:~ 18:33:49
> # ifconfig
> eth0  Link encap:Ethernet  HWaddr 50:ff:99:30:13:10  
>   inet addr:192.168.199.100  Bcast:192.168.199.255  Mask:255.255.255.0
>   inet6 addr: fe80::52ff:99ff:fe30:1310/64 Scope:Link
>   UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>   RX packets:3585 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:1318 errors:0 dropp

Re: [strongSwan] StrongSwan - can't route traffic over it

2018-03-13 Thread Noel Kuntze

You need to accepts ESP packets in *filter INPUT (-p esp).

On 12.03.2018 06:01, Brenden wrote:
> I'm guessing my NAT rules may be messed up, any ideas what might be wrong?
> 
> 
> # iptables-save
> # Generated by iptables-save v1.6.0 on Mon Mar 12 14:22:04 2018
> *nat
> :PREROUTING ACCEPT [14:1916]
> :INPUT ACCEPT [14:1916]
> :OUTPUT ACCEPT [37:2220]
> :POSTROUTING ACCEPT [18:1080]
> -A POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT
> -A POSTROUTING -s 1.2.3.112/24  -o ens33 -m policy --dir 
> out --pol ipsec -j ACCEPT
> -A POSTROUTING -s 1.2.3.112/24  -o ens33 -j MASQUERADE
> -A POSTROUTING -s 1.2.3.112/24  -o ens33 -m policy --dir 
> out --pol ipsec -j ACCEPT
> -A POSTROUTING -s 1.2.3.112/24  -o ens33 -j MASQUERADE
> COMMIT
> # Completed on Mon Mar 12 14:22:04 2018
> # Generated by iptables-save v1.6.0 on Mon Mar 12 14:22:04 2018
> *filter
> :INPUT ACCEPT [74:14670]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [215:33304]
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -p udp -m udp --dport 500 -j ACCEPT
> -A INPUT -p udp -m udp --dport 4500 -j ACCEPT
> -A FORWARD -s 1.2.3.112/24  -m policy --dir in --pol 
> ipsec --proto esp -j ACCEPT
> -A FORWARD -d 1.2.3.112/24  -m policy --dir out --pol 
> ipsec --proto esp -j ACCEPT
> -A FORWARD -s 1.2.3.112/24  -m policy --dir in --pol 
> ipsec --proto esp -j ACCEPT
> -A FORWARD -d 1.2.3.112/24  -m policy --dir out --pol 
> ipsec --proto esp -j ACCEPT
> COMMIT
> # Completed on Mon Mar 12 14:22:04 2018
> 
> 
> On 8 March 2018 at 20:34, Noel Kuntze 
>  > wrote:
> 
> Hi,
> 
> Your iptables rules in the *nat table probably cause your issue.
> 
> Take a look at the article about forwarding and split tunneling[1]. And 
> stop using `iptables -L`, it doesn't show you everything. Always use 
> `iptables-save` or `iptables-save -c` instead.
> 
> Kind regards
> 
> Noel
> 
> [1] 
> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#General-NAT-problems
>  
> 
> 
> On 07.03.2018 05:37, Brenden wrote:
> > Hi All,
> >
> > I'm attempting to run StrongSwan on Ubuntu 16.04.3 LTS.
> >
> > IPs chanaged for privacy:
> >
> > My server IP 110.0.0.110
> > My subnet is 110.0.0.0/25 
> > Internal IP: 192.168.50.214
> > Remote Peers: 1.2.3.111 (pri) / 1.2.3.112 (sec)
> >
> > The primary connection is currently not configured (its still running on
> > our hardware FW) but the secondary one has been re-configured with the
> > other peer and connection successfully establishes.
> >
> > They can see our successful connection is up but can't see any traffic
> > being sent from our side.
> >
> > I am running HAPROXY on my strongswans server which forwards traffic 
> from
> > 192.168.50.214:  to 10.4.34.70: 
>  (via IPSEC tunnel). I can't ping,
> > telnet, curl or do anything against this host.
> >
> > I have this working in a legacy (undocumented environment on a Fortigate
> > FW), but that's being replaced.
> >
> > # ipsec statusall
> > Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-109-generic,
> > x86_64):
> >   uptime: 51 minutes, since Mar 07 13:21:13 2018
> >   malloc: sbrk 2588672, mmap 0, used 588944, free 1999728
> >   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> > scheduled: 7
> >   loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random
> > nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp
> > dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr
> > kernel-netlink resolve socket-default connmark farp stroke updown
> > eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2
> > eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2
> > eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic
> > xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11
> > tnccs-dynamic dhcp lookip error-notify certexpire led addrblock unity
> > Listening IP addresses:
> >   110.0.0.110
> >   192.168.50.214
> > Connections:
> >      ipsec-pri:  110.0.0.110...1.2.3.111  IKEv1, dpddelay=30s
> >      ipsec-pri:   local:  uses pre-shared key authentication
> >      ipsec-pri:   remote: uses pre-shared key authentication
> >      ipsec-pri:   child:  110.0.0.0/25  === 
> 10.5.35.0/24  TUNNEL,
> > dpdaction=

[strongSwan] No CHILD_SA tunnel{2} established with nat public IP

2018-03-13 Thread Sujoy


Hi All,

  I am facing a issue while establish tunnel through the nated Public 
IP. When I connect to the same Strongswan server from LAN I get 
"*CHILD_SA tunnel{2} established with SPIs cb7bd615_i c3fb87d7_o and TS 
172.25.12.38/32 == 172.25.1.23/32"*. But from public network "IKE_SA 
tunnel is established but CHILD_SA tunnel" is not displayed. Even during 
the public IP tunneling- "ip route list table 220" no output in the 
server. Due to that traffic is also not passing.
The configuration file is same of both the client. It will be a big help 
if someone can provide any solution.



root@Device_BD2009:~# ipsec up tunnel
no files found matching '/etc/strongswan.d/*.conf'
initiating IKE_SA tunnel[1] to X.X.X.X
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) ]

sending packet: from 192.168.1.100[500] to X.X.X.X[500] (1080 bytes)
received packet: from X.X.X.X[500] to 192.168.1.100[500] (464 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) 
N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]

local host is behind NAT, sending keep alives
remote host is behind NAT
authentication of '192.168.1.100' (myself) with pre-shared key
establishing CHILD_SA tunnel
generating IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH) 
N(EAP_ONLY) ]

sending packet: from 192.168.1.100[4500] to X.X.X.X[4500] (332 bytes)
received packet: from X.X.X.X[4500] to 192.168.1.100[4500] (220 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) ]
authentication of 'X.X.X.X' with pre-shared key successful
IKE_SA tunnel[1] established between 
192.168.1.100[192.168.1.100]...X.X.X.X[X.X.X.X]

scheduling reauthentication in 10015s
maximum IKE_SA lifetime 10555s
connection 'tunnel' established successfully


config setup

    charondebug="all"
    uniqueids=no
    strictcrlpolicy=no
conn %default
conn tunnel #
   left=192.168.1.100
   leftsubnet=192.168.1.100/32
   right=X.X.X.X
   rightsubnet=X.X.X.X/32
   ike=aes256-sha1-modp2048
   esp=aes256-sha1
   keyingtries=1
   keylife=60m
   dpddelay=30s
   dpdtimeout=150s
   dpdaction=clear
   authby=psk
   auto=route
   keyexchange=ikev2
   type=tunnel
   mobike=no
   fragmentation=yes

--
Thanks in advance.

Re: [strongSwan] Diffie Hellman group 14 private exponent size

2018-03-13 Thread Tobias Brunner

Hi Mike,

> We use in the ipsec.conf the configuration:
>     ike=aes256-sha256-modp2048,aes256-sha1-modp2048!
>     esp=aes256-sha256-modp2048,aes256-sha1-modp2048!
> 
> How big is the size of the private exponent at least, or could a size of
> 256 bit guaranteed?

Depends on the dh_exponent_ansi_x9_42 strongswan.conf setting.  If it is
enabled (default) the size of the private exponent will equal that of
the prime (2048 bit), otherwise, the size is determined roughly
according to RFC 3526 and in this case will be 384 bit.

Regards,
Tobias

Re: [strongSwan] RSA_EMSA_PKCS1_SHA1 not acceptable

2018-03-13 Thread Tobias Brunner

Hi Mike,

> I hope you mean the ipsec.conf only:
> 
> Ipsec.conf:
> config setup
> charondebug="cfg 2, dmn 1, ike 1, net 1, job 0"
> 
> conn %default
> keyexchange=ikev2
> ike=aes256-sha256-modp2048,aes256-sha1-modp2048!
> esp=aes256-sha256-modp2048,aes256-sha1-modp2048!
> leftauth=pubkey-sha256
> rightauth=pubkey-sha256

There you go.  If you require the client authentication to use SHA-256,
but don't actually configure your client to use SHA-256 (the default
depends on the key size) you get exactly the error message you saw.

> dpdaction=clear
> dpddelay=300s
> rekey=yes
> left=%any
> leftsubnet=0.0.0.0/0
> right=%any
> lifetime=24h
> ikelifetime=168h
> compress=yes
> 
> ca %default
>   certuribase=http://hashandurl.gto1-ref.service-ti.de/
> 
> ca GEM.VPNK-CA27
>   cacert = GEM_VPNK-CA27TEST-ONLY.pem
>   auto=add
> 
> ca GEM.RCA2
>   cacert = GEM.RCA2.der
>   auto=add
> 
> conn RU1-TI
>keyexchange=ikev2
>left=vpn1-ti.gto1-ref.service-ti.de
>leftcert=vpn1-ti.gto1-refCert.pem
>leftid="C=DE, O=Arvato Systems GmbH TEST-ONLY - NOT-VALID, 
> CN=vpn1-ti.gto1-ref.service-ti.de"
>leftfirewall=yes
>right=%any
>rightsourceip=10.23.0.0/20
>auto=add

Regards,
Tobias

[strongSwan] Diffie Hellman group 14 private exponent size

2018-03-13 Thread Mike.Ettrich

Hi!

We use in the ipsec.conf the configuration:

ike=aes256-sha256-modp2048,aes256-sha1-modp2048!
esp=aes256-sha256-modp2048,aes256-sha1-modp2048!

How big is the size of the private exponent at least, or could a size of 256 
bit guaranteed?

Kind regards,
Mike.


Mike Ettrich
Software Developer | Solution Architect
-
Arvato Systems Perdata GmbH
Joachim-Jungius-Straße 9
18059 Rostock
Germany

Phone: +49(5241)80-40258
Fax: +49(5241)80-9690

E-Mail: mike.ettr...@bertelsmann.de
IT.arvato.com

Immer auf dem Laufenden: Hier zum Arvato Systems 
Newsletter
 anmelden!
Always up-to-date: Subscribe to the Arvato Systems 
Newsletter
 here!
--
Follow us on Twitter (@arvatosystems) * 
LinkedIn * 
Google+ * 
Xing
--
Arvato Systems Perdata GmbH: Sitz/Registered Office Leipzig | 
Amtsgericht/District Court Leipzig Commercial Registry HRB 15 784
Geschäftsführer/Managing Directors: Dr. Percy Dahm | Hartmut Fries 
(Vorsitzender/Chairman)
---
Bitte denken Sie über Ihre Verantwortung gegenüber der Umwelt nach, bevor Sie 
diese E-Mail ausdrucken!
Please consider your environmental responsibility before printing this e-mail!

Re: [strongSwan] RSA_EMSA_PKCS1_SHA1 not acceptable

2018-03-13 Thread Tobias Brunner

Hi Mike,

> If you need more installation or configuration details please let me know.

The (complete) server config might help.

Regards,
Tobias

Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

2018-03-13 Thread Andreas Steffen

Hi,

I don't see the virtual IP address 10.2.1.211/32 installed on your
physical USB interface with IP address 10.39.63.211. Does the command

  ip route list table 220

show any source route entries?

Regards

Andreas

On 12.03.2018 11:45, Shuchen He wrote:
> Hi,
> 
> I have setup a VPN between ASA and strongswan using IKE1. The strongswan
> work as remote VPN using PSK XAuth.
> 
> The VPN tunnel is up but I can not ping the remote site. Below is the
> configuration and some output.
> 
> My observation at the moment is that the Linux kernel has setup
> everything but the TS traffic just does not leave the Linux box.  When I
> ping remote site, I can see "ip xfrm state" actually shows a flow for my
> traffic... but the flow is somehow dropped by either the kernel or
> strongswan.
> 
>  Can you please let me know what else I should do to further
> troubleshoot the issue?
> 
> *Configuration
> *
> connections {
>     home {
>     aggressive = yes
>     dpd_delay = 30
>     dpd_timeout = 90
>     version = 1
>     remote_addrs = 126.2.1.4
>     # uncomment if the responder only supports crappy crypto. But
> seriously,
>     # every single one of those algorithms is broken. Better spend
> some $$$
>     # on a better solution.
>     proposals = aes256-sha1-modp1024
>     vips = 0.0.0.0,::
>     local-1 {
>     auth = psk
>     id = acompanyTest
>     }
>     local-2 {
>     auth = xauth-generic
>     xauth_id = acompanyTest
>     }
>     remote-1 {
>     auth = psk
>     # You might have to set this to the correct value, if the
> responder isn't configure correctly.
>     #id = 126.2.1.4
>     }
>     children {
>     home {
>     remote_ts = 10.2.1.0/24
>         #local_ts=192.168.199.0/24,0.0.0.0
>     # uncomment if the responder only supports crappy
> crypto. But seriously,
>     # every single one of those algorithms is broken. Better
> spend some $$$
>     # on a better solution.
>     # esp_proposals = 3des-md5!
>     # Use this, if you want PFS with DH group 2.
>     # esp_proposals = 3des-md5-modp1024!
>         esp_proposals = aes128-sha1-modp768
>     }
>     }
>    }
> }
>     secrets {
>     ike-home {
>     id = 126.2.1.4
>     secret = "acompany123"
>     }
>     eap-home {
>     id = acompanyTest
>     secret = "acompany123"
>     }
>     }
> 
> # ipsec statusall
> Status of IKE charon daemon (strongSwan 5.6.2, Linux
> 3.0.35-2666-gbdde708-g889281e-dirty, armv7l):
>   uptime: 18 minutes, since Mar 12 18:15:45 2018
>   malloc: sbrk 253952, mmap 0, used 158560, free 95392
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
> scheduled: 6
>   loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce
> x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey
> sshkey pem fips-prf gmp curve25519 xcbc cmac hmac attr kernel-netlink
> resolve socket-default stroke vici updown xauth-generic counters
> Listening IP addresses:
>   192.168.199.100
>   192.168.199.254
>   192.168.199.141
>   192.168.126.1
>   10.39.63.211
> Connections:
>     site:  %any...126.2.1.4  IKEv1
>     site:   local:  [mylocalsite] uses pre-shared key authentication
>     site:   remote: uses pre-shared key authentication
>     site:   child:  192.168.199.0/24 === 10.2.1.0/24 TUNNEL
>     home:  %any...126.2.1.4  IKEv1 Aggressive, dpddelay=30s
>     home:   local:  [acompanyTest] uses pre-shared key authentication
>     home:   local:  uses XAuth authentication: generic with XAuth
> identity 'acompanyTest'
>     home:   remote: uses pre-shared key authentication
>     home:   child:  dynamic === 10.2.1.0/24 TUNNEL, dpdaction=clear
> Routed Connections:
>     site{1}:  ROUTED, TUNNEL, reqid 1
>     site{1}:   192.168.199.0/24 === 10.2.1.0/24
> Security Associations (1 up, 0 connecting):
>     home[1]: ESTABLISHED 17 minutes ago,
> 10.39.63.211[acompanyTest]...126.2.1.4[126.2.1.4]
>     home[1]: IKEv1 SPIs: 504550d01ee905e2_i* 2311e0ae0c6c454f_r,
> rekeying in 3 hours
>     home[1]: IKE proposal:
> AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>     home{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs:
> cc621d5e_i 3545bd6a_o
>     home{2}:  AES_CBC_128/HMAC_SHA1_96/MODP_768, 0 bytes_i, 0
> bytes_o, rekeying in 40 minutes
>     home{2}:   10.2.1.211/32 === 10.2.1.0/24
> root@wheezy-armel:~ 18:33:49
> # ifconfig
> eth0  Link encap:Ethernet  HWaddr 50:ff:99:30:13:10  
>   inet addr:192.168.199.100  Bcast:192.168.199.255 
> Mask:255.255.255.0
>   inet6 addr: fe80::52ff:99ff:fe30:1310/64 Scope:Link
>   UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>   RX packets:3585 errors:0 dropped:0 overruns:0 frame:0
>

Re: [strongSwan] Site to site VPN initiated from a NAT router

2018-03-13 Thread Zachary Cutlip

I’ve tweaked my iptables rules, and now traffic from the strongswan client box 
gets routed through the tunnel as expected. Also wifi client (10.88.88.0) 
traffic now gets routed, where it wasn’t before. However, that traffic still 
isn’t going through the tunnel.

Here are the iptables rules when the ipsec connection is established:

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  anywhere 10.19.48.2   policy match dir 
in pol ipsec reqid 1 proto esp

Chain FORWARD (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  anywhere 10.19.48.2   policy match dir 
in pol ipsec reqid 1 proto esp
ACCEPT all  --  10.19.48.2   anywhere policy match dir 
out pol ipsec reqid 1 proto esp

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  10.19.48.2   anywhere policy match dir 
out pol ipsec reqid 1 proto esp

$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  10.88.88.0/24anywhere policy match dir 
out pol ipsec
MASQUERADE  all  --  10.88.88.0/24anywhere


> On Mar 12, 2018, at 7:36 PM, Zachary Cutlip  wrote:
> 
> Hello,
> 
> I’m trying to set up an IPSec VPN that’s a little different from most 
> projects I’ve seen documented.
> 
> I’m building a NAT router on Debian that I plan to travel with. I guess you 
> might say my strongswan use case is sort of a hybrid between road warrior & 
> site-to-site.
> 
> I’m confused on how to set up ipsec.conf and iptables such that all wifi 
> clients on connecting to the NAT router/WiFi AP get their traffic routed over 
> the tunnel.
> 
> Here are some details:
> 
> The Debian box has two interfaces
> - wan0, internet facing, configured via DHCP via whatever network its 
> connected to
> - lan0, WiFi interface in AP mode with hostapd, 10.88.88.1/24, 
> (There is also a third interface for management: eth0:10.99.99.1)
> 
> dnsmasq gives out DHCP configuration to wifi clients over lan0.
> 
> I’m connecting to a strongswan instance hosted on digital ocean with a fixed 
> IP address.
> 
> When I take the box out of NAT router mode by flushing IPtables, I can 
> initiate a connection to the remote instance, and traffic originating from 
> the Debian box seems to go over the tunnel as expected. If I have iptables 
> set up to do NAT routing, and then initiate the VPN connection, two things 
> happen:
> 1. Traffic from the Debian box (such as traceroute 8.8.8.8) is no longer 
> routed over the tunnel.
> 2. Traffic from the wifi clients doesn’t get routed at all.
> 
> I feel like this should be pretty straightforward; I’m just missing 
> something. Any advice?
> 
> Here’s what my iptables looks like when the NAT router is working, and there 
> are no ipsec connections:
> 
> sudo iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere ctstate 
> RELATED,ESTABLISHED
> ACCEPT all  --  anywhere anywhere
> 
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> 
> $ sudo iptables -t nat -L
> Chain PREROUTING (policy ACCEPT)
> target prot opt source   destination
> 
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain POSTROUTING (policy ACCEPT)
> target prot opt source   destination
> MASQUERADE  all  --  anywhere anywhere
> 
> Here’s the ipsec.conf generated by Trail of Bits’s AlgoVPN (I added the 
> passthroughs):
> 
> $ cat ipsec.conf
> conn ikev2-165.x.x.x
>fragmentation=yes
>rekey=no
>dpdaction=clear
>keyexchange=ikev2
>compress=no
>dpddelay=35s
> 
>
> ike=aes128gcm16-prfsha512-ecp256,aes128-sha2_512-prfsha512-ecp256,aes128-sha2_384-prfsha384-ecp256!
>esp=aes128gcm16-ecp256,aes128-sha2_512-prfsha512-ecp256!
> 
>right=165.x.x.x
>rightid=165.x.x.x
>rightsubnet=0.0.0.0/0
>rightauth=pubkey
> 
>leftsourceip=%config
>leftauth=pubkey
>leftcert=zach.crt
>leftfirewall=yes
>left=%defaultroute
> 
>auto=add
> 
> conn mgmt-passthrough
>leftsubnet=10.99.99.0/24 # Replace with your LAN subnet
>rightsubnet=10.99.99.0/24 # Replac with your LAND subnet
>authby=never # No authentication necessary
>type=pass # passth

Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

Re: [strongSwan] StrongSwan - can't route traffic over it

Re: [strongSwan] Site to site VPN initiated from a NAT router

Re: [strongSwan] No CHILD_SA tunnel{2} established with nat public IP

Re: [strongSwan] Site to site VPN initiated from a NAT router

Re: [strongSwan] ipsec tunnel throughput measurement

Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

Re: [strongSwan] StrongSwan - can't route traffic over it

[strongSwan] No CHILD_SA tunnel{2} established with nat public IP

Re: [strongSwan] Diffie Hellman group 14 private exponent size

Re: [strongSwan] RSA_EMSA_PKCS1_SHA1 not acceptable

[strongSwan] Diffie Hellman group 14 private exponent size

Re: [strongSwan] RSA_EMSA_PKCS1_SHA1 not acceptable

Re: [strongSwan] Strongswan IPSec VPN is up but does not pass traffic

Re: [strongSwan] Site to site VPN initiated from a NAT router

16 matches

Site Navigation

Mail list logo

Footer information