Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

2021-09-01 Thread Tiago Stoco
Hi Noel,

I have disabled the forecast plugin and MARK rules aren't being added to 
iptables anymore.

The following plugins are disabled at the moment :

[root@arch-linux ~]# cat /etc/strongswan.conf
...
bypass-lan {
   load = no
   }
   connmark {
   load = no
   }
   forecast {
   load = no
   }
...

When a capture is run on the VTI device I can see the pings from the pfSense 
arriving and the reply 👇

No.   Time  Source Destination
5 2.050455 10.10.10.1 > 10.10.10.2 ICMP 84 Echo (ping) request  id=0xc4f5, 
seq=2/512, ttl=64 (reply in 6)
6 2.050467 10.10.10.2 > 10.10.10.1 ICMP 84 Echo (ping) replyid=0xc4f5, 
seq=2/512, ttl=64 (request in 5)

Strange is the fact that I see the replies in the filter OUTPUT chain not 
encapsulated nor encrypted 👇

No.   Time  Source Destination
11 9.653361 10.10.10.2 > 10.10.10.1 ICMP 116 Echo (ping) replyid=0x80f2, 
seq=2/512, ttl=64

According to my understanding, the reply should be marked, dealt with the IPSec 
stack, and tunneled to the peer since it is on the VTI interface. Please 
correct me if I am wrong.

In regards to using an XFRM, the problem is that OpenWRT does not support XFRM 
devices. A newer release will support but the current is not available yet.

[root@arch-linux ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.3, Linux 5.13.12-arch1-1, x86_64):
 uptime: 9 hours, since Sep 01 21:37:46 2021
 malloc: sbrk 3137536, mmap 0, used 1156720, free 1980816
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 
4
 loaded plugins: charon ldap pkcs11 aes des rc2 sha2 sha3 sha1 md5 mgf1 random 
nonce x509 revocation constraints pubkey p
kcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 
agent chapoly xcbc cmac hmac ntru drbg newho
pe bliss curl sqlite attr kernel-netlink resolve socket-default farp stroke 
vici updown eap-identity eap-sim eap-aka eap-a
ka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 
eap-dynamic eap-radius eap-tls eap-ttls eap-p
eap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp radattr unity counters
Listening IP addresses:
 192.168.45.30
 10.10.10.2
Connections:
   ipseclab:  192.168.45.30...192.168.45.10  IKEv2, dpddelay=10s
   ipseclab:   local:  [ipsec-lab-openwrt] uses pre-shared key authentication
   ipseclab:   remote: [ipsec-lab-pfsense] uses pre-shared key authentication
   con1:   child:  10.10.10.0/30 === 10.10.10.0/30 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
   ipseclab[4]: ESTABLISHED 2 hours ago, 
192.168.45.30[ipsec-lab-openwrt]...192.168.45.10[ipsec-lab-pfsense]
   ipseclab[4]: IKEv2 SPIs: 8b7b5c0ccf5b_i 9673036f29862401_r*, rekeying in 
4 hours
   ipseclab[4]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
   con1{12}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cef2dc29_i ccb51306_o
   con1{12}:  AES_GCM_16_256/MODP_2048, 0 bytes_i, 0 bytes_o, rekeying in 
14 minutes
   con1{12}:   10.10.10.0/30 === 10.10.10.0/30

Many Thanks !!


From: Noel Kuntze
Sent: Wednesday, September 1, 2021 1:23 AM
To: Tiago Stoco; Noel Kuntze; Tobias Brunner; users@lists.strongswan.org
Subject: Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors 
NoRoute

Hi Tiago,

Try disabling the forecast plugin too, please.

With VTIs, you shouldn't need to manually mark the packets.

Btw, if you use an XFRM interface instead, you won't have as many problems 
because the field used for
typing the interface and the policies together isn't used for anything else (In 
comparison to the fwmark field,
which as you can see can be used for all sorts of things).

>
> I will add to the thread later but NFLOG is able to capture MARKS in the 
> packets. The packets captured by NFLOG has a special section with quite 
> useful information.
> ...
> Linux Netfilter NFLOG
>  Family: IPv4 (2)
>  Version: 0
>  Resource id: 7
>  TLV Type: NFULA_PACKET_HDR (1), Length: 8
> ...

That doesn't look like a mark field to me. It'd need to be 32 bit in length and 
have the same value as the (fw)mark field in iptables.

Kind regards
Noel


Am 01.09.21 um 01:46 schrieb Tiago Stoco:
> Hi Noel,
>
> Thanks for the help.
>
> I have moved the route for IPSec back into the main routing table.
>
> [root@arch-linux ~]# ip route
> default via 192.168.45.1 dev ens18
> 10.10.10.0/30 dev ip_vti1 scope link src 10.10.10.2
> 192.168.45.0/24 dev ens18 proto kernel scope link src 192.168.45.30
>
> [root@arch-linux ~]# ip route show table 220
> [root@arch-linux ~]#
>
> And the connmark plugin has been disabled.
>
> [root@arch-linux ~]# ipsec statusall | grep -i connmark
> [root@arch-linux ~]#
>
> Also, I have noticed that even after the connmark plugin is disabled some 
> mark rules are added to iptables.
>
> [root@arch-linux ~]# ipsec sto

Re: [strongSwan] strongswan no shared key found

2021-09-01 Thread Noel Kuntze

Hello Chasing,

Make sure the configuration and the secrets is actually loaded (swanctl -q).
Is server_publicip == serveraddr?

Kind regards
Noel

Am 20.08.21 um 02:02 schrieb Chasing Vega:

Hi

I have a server which is public and accepts IPsec and am trying to connect to 
it through strong

My configuration for strongswan is

connections {
     my-vpn {
         remote_addrs = server_publicip
         version = 1
         proposals = aes256-sha-modp1024
         reauth_time = 1440m
         local {
             auth = psk
             id = loc
         }
         remote {
             # id field here is inferred from the remote address
             auth = psk
             id = sec
         }
         children {
             my-vpn-1 {
                 local_ts = local_public_ip
                 remote_ts = server_public_ip
                 mode = transport
                 esp_proposals = aes256-sha-modp1024
                 rekey_time = 60m
                 start_action = trap
                 dpd_action = restart
             }
         }
     }

}
secrets {
    ike-my-vpn-1 {
        id-1 = loc
        id-2 = sec
        secret = "This is a strong password"
    }
}

When I try to run strongswan I get

[IKE] initiating Main Mode IKE_SA my-vpn[49] to serveraddr
[ENC] generating ID_PROT request 0 [ SA V V V V V ]
[NET] sending packet: from locip[500] to serveraddr[500] (184 bytes)
[NET] received packet: from serveraddr[500] to locip[500] (108 bytes)
[ENC] parsed ID_PROT response 0 [ SA V ]
[IKE] received NAT-T (RFC 3947) vendor ID
[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[NET] sending packet: from locip[500] to serveraddr[500] (244 bytes)
[NET] received packet: from serveraddr[500] to locip[500] (304 bytes)
[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
[IKE] received Cisco Unity vendor ID
[IKE] received DPD vendor ID
[ENC] received unknown vendor ID: 
5d:4b:ac:66:6b:54:71:15:4b:07:98:9c:05:7e:be:f2
[IKE] received XAuth vendor ID
[IKE] no shared key found for 'loc'[locip] - 'sec'[serveraddr]
[IKE] no shared key found for locip - serveraddr
[ENC] generating INFORMATIONAL_V1 request 1109914452 [ N(INVAL_KE) ]
[NET] sending packet: from locip[500] to serveraddr[500] (56 bytes)


Does anyone have suggestion?




OpenPGP_signature
Description: OpenPGP digital signature


Re: [strongSwan] Questions for setting up host-host configuration.

2021-09-01 Thread Noel Kuntze

Hello Jason,

You're entirely on your own there.
The project does not support such old versions in any capacity.

Kind regards
Noel

Am 21.08.21 um 09:54 schrieb Jason Choi:

I used StrongSwan-4.2.17 and tried to set up host-host configuration following the 
explanation from https://www.strongswan.org/docs/readme4.htm 
.

My configuration is like this.

    [ 192.168.1.207 ] = [192.168.1.206]

  ss_client       ss_server

<< Configuration on host ss_client >>

/etc/ipsec.d/cacerts/strongswanCert.pem

/etc/ipsec.d/certs/ss_client.pem

/etc/ipsec.d/private/ss_client.key

/etc/ipsec.secrets:

: RSA ss_client.key

/etc/ipsec.conf

conn  host-host

   left=%defaultroute

   leftcert=ss_client.pem

   right=192.168.1.206

   rightid="C=US, O=Home, CN=ss_server.research-this-that.com"

   auto=start

<< Configuration on host ss_server >>

/etc/ipsec.d/cacerts/strongswanCert.pem

/etc/ipsec.d/certs/ss_server.pem

/etc/ipsec.d/private/ss_server.key

/etc/ipsec.secrets:

: RSA ss_server.key

/etc/ipsec.conf

conn  host-host

   left=%defaultroute

   leftcert=ss_server.pem

   right=192.168.1.207

   rightid="C=US, O=Home, CN=ss_client.research-this-that.com"

   auto=start

And this is a message when I run ipsec statusall from each host.

Would someone can give me any idea what was wrong?

Or if you need more information from my settings and configuration, please let 
me know.

<< ipsec statusall from ss_client >>

# ipsec statusall

000 interface lo/lo ::1:500

000 interface lo/lo 127.0.0.1:500

000 interface eth0/eth0 192.168.1.207:500

000 interface virbr0/virbr0 192.168.122.1:500

000 %myid = (none)

000 debug none

000

000 "host-host": 192.168.1.207[C=US, O=Home, 
CN=ss_client.research-this-that.com]---192.168.1.1...192.168.1.206[C=US, O=Home, 
CN=ss_server.research-this-that.com]; unrouted; eroute owner: #0

000 "host-host":   CAs: 'C=US, O=Home, 
CN=ss_server.research-this-that.com'...'%any'

000 "host-host":   ike_life: 10800s; ipsec_life: 3600s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 3

000 "host-host":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP; prio: 32,32; 
interface: eth0;

000 "host-host":   newest ISAKMP SA: #0; newest IPsec SA: #0;

000 "host-host":   IKE algorithms wanted: 7_128-2-14,

000 "host-host":   IKE algorithms found:  7_128-2_160-14,

000 "host-host":   ESP algorithms wanted: 12_128-2, 3_000-1,

000 "host-host":   ESP algorithms loaded: 12_128-2_160, 3_192-1_128,

000

000 #1: "host-host" STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_RETRANSMIT 
in 30s

000 #1: pending Phase 2 for "host-host" replacing #0

000

<< ipsec statusall from ss_server >>

# ipsec statusall

000 interface lo/lo ::1:500

000 interface lo/lo 127.0.0.1:500

000 interface eth0/eth0 192.168.1.206:500

000 interface virbr0/virbr0 192.168.122.1:500

000 %myid = (none)

000 debug none

000

000 "host-host": 192.168.1.206[C=US, O=Home, 
CN=ss_server.research-this-that.com]---192.168.1.1...192.168.0.1[C=US, O=Home, 
CN=ss_client.research-this-that.com]; unrouted; eroute owner: #0

000 "host-host":   CAs: 'C=US, O=Home, 
CN=ss_server.research-this-that.com'...'%any'

000 "host-host":   ike_life: 10800s; ipsec_life: 3600s; rekey_margin: 540s; 
rekey_fuzz: 100%; keyingtries: 3

000 "host-host":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP; prio: 32,32; 
interface: eth0;

000 "host-host":   newest ISAKMP SA: #0; newest IPsec SA: #0;

000 "host-host":   IKE algorithms wanted: 7_128-2-14,

000 "host-host":   IKE algorithms found:  7_128-2_160-14,

000 "host-host":   ESP algorithms wanted: 12_128-2, 3_000-1,

000 "host-host":   ESP algorithms loaded: 12_128-2_160, 3_192-1_128,

000

000 #1: "host-host" STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_RETRANSMIT 
in 1s

000 #1: pending Phase 2 for "host-host" replacing #0

000

Windows の メール  から送信





OpenPGP_signature
Description: OpenPGP digital signature


Re: [strongSwan] Problem on Vodafone in India

2021-09-01 Thread Noel Kuntze

Hello John,

There must be more going on.
strongSwan configuration does not influence DNS resolution in any way.

Kind regards
Noel

Am 29.08.21 um 15:38 schrieb John Serink:

Hello:

We are running the following on a Teltonika RUT-950 router:
root@CORS144:~# ipsec --version
Linux strongSwan U5.6.2/K3.18.44
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.

I am not sure if this is a strongswan issue or not.
IPv6 is disabled on the router:
root@CORS144:/# cat /proc/sys/net/ipv6/conf/default/disable_ipv6
1
root@CORS144:/# cat /proc/sys/net/ipv6/conf/all/disable_ipv6
1

We use 2 cell providers in India, Airtel and Vodafone. Airtel works as 
expected, no issues.
Vodafone has a strange problem.
1. It can take upto 3 minutes for a connection to come up, so strongswan fails 
as the name
lookup fails for our IPSec responder,

2. When the connection finally does come up, from another ssh console I can 
ping our IPSec
responder but watching the log, using logread -f, I see strongswan trying to 
connect to the
IPSec responder using an IPV6 address.

Why is it doing that? We have disabled IPV6 but nslookup is returning an IPv4 
and IPV6 address
for the responder.

We never have this issue with airtel.
But it gets more interesting:
3. If I setup the ipsec.conf (/etc/config/strongwan) as:

right   TheFullyQualifiedDomainName

and then I do this:

nslookup TheFullyQualifiedDomainName

I will get an IPv4 and IPv6 address and strongswan will use the IPv6 
address.there is no
vpn setup on the IPv6 address of the destination responder.
4. If I setup ipsec.conf (/etc/config/strongswan) like this:

right   A.B.C.D

and then I do this:

nslookup TheFullyQualifiedDomainName

I will get only the IPv4 address A.B.C.D and strongswan will use this for the 
connection and
it works.

But if we use airtel, it works either way.

Can anyone make sense of this?

So, my question is:
Does this seem like a strongswan issue or an RUT-950 system issue?

We have a work around which is to use the IP address of the responder as item 4 
which is a
non-ideal solution if we change ISPs at the control centreas then I'd have 
to manually go
through 280 routers so I'd like to stay with the FQDN if possible.

Cheers,
john





OpenPGP_signature
Description: OpenPGP digital signature


Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

2021-09-01 Thread Noel Kuntze

Hi Tiago,

Try disabling the forecast plugin too, please.

With VTIs, you shouldn't need to manually mark the packets.

Btw, if you use an XFRM interface instead, you won't have as many problems 
because the field used for
typing the interface and the policies together isn't used for anything else (In 
comparison to the fwmark field,
which as you can see can be used for all sorts of things).



I will add to the thread later but NFLOG is able to capture MARKS in the 
packets. The packets captured by NFLOG has a special section with quite useful 
information.
...
Linux Netfilter NFLOG
     Family: IPv4 (2)
     Version: 0
     Resource id: 7
     TLV Type: NFULA_PACKET_HDR (1), Length: 8
...


That doesn't look like a mark field to me. It'd need to be 32 bit in length and 
have the same value as the (fw)mark field in iptables.

Kind regards
Noel


Am 01.09.21 um 01:46 schrieb Tiago Stoco:

Hi Noel,

Thanks for the help.

I have moved the route for IPSec back into the main routing table.

[root@arch-linux ~]# ip route
default via 192.168.45.1 dev ens18
10.10.10.0/30 dev ip_vti1 scope link src 10.10.10.2
192.168.45.0/24 dev ens18 proto kernel scope link src 192.168.45.30

[root@arch-linux ~]# ip route show table 220
[root@arch-linux ~]#

And the connmark plugin has been disabled.

[root@arch-linux ~]# ipsec statusall | grep -i connmark
[root@arch-linux ~]#

Also, I have noticed that even after the connmark plugin is disabled some mark 
rules are added to iptables.

[root@arch-linux ~]# ipsec stop
Stopping strongSwan IPsec...
[root@arch-linux ~]# iptables-save | grep -i mark
[root@arch-linux ~]#

[root@arch-linux ~]# ipsec start
Starting strongSwan 5.9.3 IPsec [starter]...
[root@arch-linux ~]# swanctl --load-all
plugin 'mysql' failed to load: libmariadb.so.3: cannot open shared object file: 
No such file or directory
loaded ike secret 'ike-0'
no authorities found, 0 unloaded
no pools found, 0 unloaded
loaded connection 'ipseclab'
successfully loaded 1 connections, 0 unloaded
[root@arch-linux ~]# iptables-save | grep -i mark
-A PREROUTING -d 10.10.10.0/30 -j MARK --set-xmark 0x2a/0x
-A PREROUTING -s 192.168.45.10/32 -d 192.168.45.30/32 -p esp -m esp --espspi 
3419086685 -j MARK --set-xmark 0x2a/0xfff
f
-A OUTPUT -d 10.10.10.0/30 -j MARK --set-xmark 0x2a/0x


The scenario is the same at the moment :

pings from 10.10.10.1 ( pfSense ) to 10.10.10.2 ( Linux ) ✅ seem as received by 
Linux
pings from 10.10.10.2 ( Linux ) to 10.10.10.1 ( pfSense ) ❌ seem as Errors 
NoRoute
ip_vti1: ip/ip remote 192.168.45.10 local 192.168.45.30 ttl inherit nopmtudisc 
key 42
RX: Packets    Bytes    Errors CsumErrs OutOfSeq Mcasts
   66095  5551980  0  0    0    0
TX: Packets    Bytes    Errors DeadLoop NoRoute  NoBufs
   0  0    133788 0    133788   0

I am at work and not able to capture packets to further investigate but will do 
as soon possible.

[root@arch-linux ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.3, Linux 5.13.12-arch1-1, x86_64):
 uptime: 9 minutes, since Sep 01 00:24:27 2021
 malloc: sbrk 2936832, mmap 0, used 1328288, free 1608544
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 
115
 loaded plugins: charon ldap pkcs11 aes des rc2 sha2 sha3 sha1 md5 mgf1 random 
nonce x509 revocation constraints pubkey p
kcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 
agent chapoly xcbc cmac hmac ntru drbg newho
pe bliss curl sqlite attr kernel-netlink resolve socket-default forecast farp 
stroke vici updown eap-identity eap-sim eap-
aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc 
eap-mschapv2 eap-dynamic eap-radius eap-tls eap-t
tls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp radattr unity 
counters
Listening IP addresses:
 192.168.45.30
 10.10.10.2
Connections:
   ipseclab:  192.168.45.30...192.168.45.10  IKEv2, dpddelay=10s
   ipseclab:   local:  [ipsec-lab-openwrt] uses pre-shared key authentication
   ipseclab:   remote: [ipsec-lab-pfsense] uses pre-shared key authentication
   con1:   child:  10.10.10.0/30 === 10.10.10.0/30 TUNNEL, dpdaction=restart
Security Associations (2 up, 0 connecting):
   ipseclab[54]: ESTABLISHED 9 seconds ago, 
192.168.45.30[ipsec-lab-openwrt]...192.168.45.10[ipsec-lab-pfsense]
   ipseclab[54]: IKEv2 SPIs: 840c3fd77eb0efee_i b3f6cec233130e6a_r*, rekeying 
in 6 hours
   ipseclab[54]: IKE proposal: 
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
   con1{54}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c206ad8c_i c631ebba_o
   con1{54}:  AES_GCM_16_256, 0 bytes_i, 0 bytes_o, rekeying in 48 minutes
   con1{54}:   10.10.10.0/30 === 10.10.10.0/30
   ipseclab[53]: ESTABLISHED 19 seconds ago, 
192.168.45.30[ipsec-lab-openwrt]...192.168.45.10[ipsec-lab-pfsense]
   ipseclab[53]: IKEv2 SPIs: 133d2066ebf6a358_i d8da41bca97601ca_r*, rekeying 
in 6 hours
   ipseclab[53]: IKE proposal: 
AES_CBC_256/HMAC_S