Re: [strongSwan] IPtables settings

2020-01-14 Thread Felipe Arturo Polanco
Those settings look good, please send this output:

$ sysctl -a | grep -e "forwarding"

On Tue, Jan 14, 2020 at 4:08 AM cristi...@newro.co 
wrote:

> Hi.
>
> Please, can anyone give some advices?
>
> Thank you!
> On 1/13/20 4:41 PM, cristi...@newro.co wrote:
>
> /etc/ipsec.conf
>
> # basic configuration
> config setup
> charondebug="all"
> uniqueids=yes
> strictcrlpolicy=no
>
> # connection 1
> conn site1-to-site2
>   authby=secret
>   left=%defaultroute
>   leftid=111.111.111.45
>   leftsubnet=172.16.11.0/24
>   right=222.222.222.210
>   rightsubnet=172.16.15.0/24
>   ike=aes256-sha2_256-modp1024!
>   esp=aes256-sha2_256!
>   keyingtries=0
>   ikelifetime=1h
>   lifetime=8h
>   dpddelay=30
>   dpdtimeout=120
>   dpdaction=restart
>   auto=start
>
> Only this file where I've defined  my site-to-site settings.
>
>
> On 1/13/20 4:36 PM, Felipe Arturo Polanco wrote:
>
> Hi,
>
> Please also send the content of /etc/ipsec.conf and/or /etc/swanctl.conf ,
> /etc/swanctl/swanctl.conf , the file where you defined your site-to-site
> settings.
>
> On Mon, Jan 13, 2020 at 10:27 AM cristi...@newro.co 
> wrote:
>
>> Also it ipsec.conf file
>>
>> # basic configuration
>> config setup
>> charondebug="all"
>> uniqueids=yes
>> strictcrlpolicy=no
>>
>> # connection to paris datacenter
>> conn totorum-to-camulodunum
>>   authby=secret
>>   left=%defaultroute
>>   leftid=111.111.111.45
>>   leftsubnet=172.16.11.0/24
>>   right=222.222.222.210
>>   rightsubnet=172.16.15.0/24
>>   ike=aes256-sha2_256-modp1024!
>>   esp=aes256-sha2_256!
>>   keyingtries=0
>>   ikelifetime=1h
>>   lifetime=8h
>>   dpddelay=30
>>   dpdtimeout=120
>>   dpdaction=restart
>>   auto=start
>>
>> On 1/13/20 4:15 PM, Felipe Arturo Polanco wrote:
>>
>> Hi,
>>
>> Please send us the following information:
>>
>> Strongswan configuration and
>> Output of:
>> iptables-save
>> ip xfrm policy
>> ip route show
>> ip rule show
>> ip address show
>>
>> Thanks,
>>
>>
>> On Mon, Jan 13, 2020 at 10:13 AM cristi...@newro.co 
>> wrote:
>>
>>> Hello,
>>>
>>> I am trying to set up a point-to-point VPN connection between two KVM
>>> hosts running Ubuntu 18.04 LTS.
>>>
>>> For struggling fro more then a week to make it work but without success.
>>>
>>> The tunnel seams to be running but I cannot make the connection between
>>> internal subenets.
>>>
>>> Can anyone tell me what iptables rules should I set?
>>>
>>> Thank you!
>>>
>>> Best regards!
>>>
>>>
>>>


Re: [strongSwan] Confused about Mac OS X IKEv2 config

2020-01-13 Thread Felipe Arturo Polanco
Got it sorted out.

If anyone is interested, the AuthenticationMethod is the local and remote
Auth methods, but, if ExtendedAuthEnabled is 1, then AuthenticationMethod
is the remote end Auth while the Local end uses EAP(XAUTH) for
authentication



On Mon, Jan 13, 2020 at 2:28 PM Felipe Arturo Polanco <
felipeapola...@gmail.com> wrote:

> Hello,
>
> I'm trying to set up a strongswan client for an IKEv2 server that works
> fine over Mac OS.
>
> They provide this mobileconfig setting but I'm confused since they are
> using PSK and Username+password at the same time, does Mac OS X support
> multiple authentication rounds in IKEv2?
> How would this file translate to a swanctl config?
>
> IKEv2
> 
>   RemoteIdentifier
>   myvpn.com
>   AuthenticationMethod
>   SharedSecret
>   SharedSecret
>   
>   LocalIdentifier
>   john003
>   RemoteAddress
>   myvpn.com
>   ExtendedAuthEnabled
>   1
>   AuthName
>   john003
>   AuthPassword
>   changeme
>
> Thanks,
>


Re: [strongSwan] IPtables settings

2020-01-13 Thread Felipe Arturo Polanco
Hi,

Please also send the content of /etc/ipsec.conf and/or /etc/swanctl.conf ,
/etc/swanctl/swanctl.conf , the file where you defined your site-to-site
settings.

On Mon, Jan 13, 2020 at 10:27 AM cristi...@newro.co 
wrote:

> Also it ipsec.conf file
>
> # basic configuration
> config setup
> charondebug="all"
> uniqueids=yes
> strictcrlpolicy=no
>
> # connection to paris datacenter
> conn totorum-to-camulodunum
>   authby=secret
>   left=%defaultroute
>   leftid=111.111.111.45
>   leftsubnet=172.16.11.0/24
>   right=222.222.222.210
>   rightsubnet=172.16.15.0/24
>   ike=aes256-sha2_256-modp1024!
>   esp=aes256-sha2_256!
>   keyingtries=0
>   ikelifetime=1h
>   lifetime=8h
>   dpddelay=30
>   dpdtimeout=120
>   dpdaction=restart
>   auto=start
>
> On 1/13/20 4:15 PM, Felipe Arturo Polanco wrote:
>
> Hi,
>
> Please send us the following information:
>
> Strongswan configuration and
> Output of:
> iptables-save
> ip xfrm policy
> ip route show
> ip rule show
> ip address show
>
> Thanks,
>
>
> On Mon, Jan 13, 2020 at 10:13 AM cristi...@newro.co 
> wrote:
>
>> Hello,
>>
>> I am trying to set up a point-to-point VPN connection between two KVM
>> hosts running Ubuntu 18.04 LTS.
>>
>> For struggling fro more then a week to make it work but without success.
>>
>> The tunnel seams to be running but I cannot make the connection between
>> internal subenets.
>>
>> Can anyone tell me what iptables rules should I set?
>>
>> Thank you!
>>
>> Best regards!
>>
>>
>>


Re: [strongSwan] IPtables settings

2020-01-13 Thread Felipe Arturo Polanco
Hi,

Please send us the following information:

Strongswan configuration and
Output of:
iptables-save
ip xfrm policy
ip route show
ip rule show
ip address show

Thanks,


On Mon, Jan 13, 2020 at 10:13 AM cristi...@newro.co 
wrote:

> Hello,
>
> I am trying to set up a point-to-point VPN connection between two KVM
> hosts running Ubuntu 18.04 LTS.
>
> For struggling fro more then a week to make it work but without success.
>
> The tunnel seams to be running but I cannot make the connection between
> internal subenets.
>
> Can anyone tell me what iptables rules should I set?
>
> Thank you!
>
> Best regards!
>
>
>


Re: [strongSwan] Roadwarrior VPN same subnet

2019-12-22 Thread Felipe Arturo Polanco
Hi,

Please share with us your Strongswan configuration, $ iptables-save
output and $ ip xfrm policy output

Also, a brief description of which network/host needs to ping which
network/host. eg: 172.16.20.14 needs to ping 10.0.10.50 over the VPN
server at 172.16.20.1


On Sat, Dec 21, 2019 at 12:37 AM Dušan Ilić  wrote:
>
>
>
>  Dušan Ilić wrote 
>
> Hi,
>
>
> I have configured a roadwarrior ikev2 strongswan setup with DHCP.
>
> Everything works when I assign the dhcp scope a separate subnet, but when I 
> assign IPs from the same subnet   it doesn't work. The strange thing is that 
> the client can still connect and the gateway and other local clients can 
> reach the VPN client with ping, but not the other way around. So the client 
> responds to pings, but cannot itself ping or reach anything.
>
>
> I have checked iptables rules, routing tables and nat. Everything looks just 
> fine. Also farp plugin is enabled.
>
>
> Do anyone recognize this behavior, if not, how should I go about 
> troubleshooting this?


Re: [strongSwan] Route-based VPNs (XFRM Interfaces) vs policies based VPNs

2019-12-20 Thread Felipe Arturo Polanco
Hi,

I have done this before, it works fine.

Just make sure you add a corresponding mark to both the definition of the
ipsec0 interface and the Strongswan config for 0.0.0.0/0

XFRM looks for the most specific traffic selector when finding a match, it
will check against route-based selector first and then will check 0.0.0.0/0
at last.

On Fri, Dec 20, 2019 at 12:57 PM Michael Schwartzkopff  wrote:

> On 20.12.19 17:42, Marco Berizzi wrote:
> > Hello everyone,
> >
> > I need to setup a 0.0.0.0/0 to 0.0.0.0/0 ipsec tunnel.
> > I was thinking to setup it with the new xfrm interfaces:
> > I don't need route all the 0.0.0.0/0 throught this vpn.
> >
> > My question is how 'route based' and 'policies based'
> > VPNs will coexist on the same linux box.
> >
> > For example, if I'm going to implement a 0.0.0.0/0 to
> > 0.0.0.0/0 vpn with the xfrm interfaces and then I will
> > route the traffic only for the 155.192.168.0/24 network
> > throught the ipsec0 device (for example), and then I
> > implement a classic policy based vpn (without the xfrm
> > interface) with the following traffic selectors
> > 166.172.16.0/24 and 177.16.172.0/24, what will happen?
> > Will the linux kernel process the packets for the
> > 166.172.16.0/24 and 177.16.172.0/24 into the right ipsec
> > policy?
> >
> > Thanks
> >
> > Marco
>
> I think mixing policy and route based VPNs on the same machine with
> overlapping network ranges will cause trouble. I'd change to only
> route-based VPNs in that case.
>
>
> Mit freundlichen Grüßen,
>
> --
>
> [*] sys4 AG
>
> https://sys4.de, +49 (89) 30 90 46 64
> Schleißheimer Straße 26/MG,80333 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
> Aufsichtsratsvorsitzender: Florian Kirstein
>
>
>


Re: [strongSwan] source NAT

2019-12-11 Thread Felipe Arturo Polanco
I believe there isn't an option for that since IPSec does not do NAT.

You can use iptables, ip rule nat and IPVS NAT for that.

On Wed, Dec 11, 2019 at 2:17 PM Matt Frederick  wrote:
>
> Hi - I'd like to hide all of network A behind a NAT as it enters the tunnel 
> bound for network B. Is there an option in ipsec.conf that I don't see which 
> would allow me to do that? Or should I stick with iptables rules? thanks! 
> -matt
>
>
> Confidentiality and Privacy Notice: Information transmitted by this email is 
> proprietary to [m]pirik and is intended for use only by the individual or 
> entity to which it is addressed, and may contain information that is private, 
> privileged, confidential or exempt from disclosure under applicable law. All 
> personal messages express views solely of the sender, are not to be 
> attributed to [m]pirik, and may not be copied or distributed without this 
> disclaimer. If you are not the intended recipient or it appears that this 
> mail has been forwarded to you without proper authority, you are notified 
> that any use or dissemination of this information in any manner is strictly 
> prohibited. In such cases, please delete this mail from your records.


[strongSwan] What is the proper way to close an ICAP transaction?

2019-11-26 Thread Felipe Arturo Polanco
Hi,

We have an ICAP server for Squid 4.

While we can successfully scan our files and do content adaptation, we have
been struggling to find a way to close the ICAP transaction before passing
the whole body back to squid and at the same time avoid squid marking one
icap failure.

This is for an ICAP server that does Virus scanning and if virus found, the
body is not sent back.

If we send an ICAP header with 500 then Squid mark us as ICAP FAILURE, if
we don't send anything then Squid keeps awaiting on us and then timeout,
increasing the icap failure counter by one and so on.

At some point squid just mark the server as down and stop sending
transactions to it.

We have been overcoming this by having a low OPTIONs TTL but that seems
inefficient for high traffic squid nodes.

Does anyone know how to proceed with this?

Thanks,


Re: [strongSwan] xauth authentication backend

2019-09-27 Thread Felipe Arturo Polanco
Hi,

You can check out multiple authentication rounds, it will provide with
chain authentication using multiple backends.

On Fri, Sep 27, 2019 at 7:38 AM Christoph Harder 
wrote:

> Hello everybody,
>
> currently I do have the problem, that I need to setup xauth but with a
> custom authentication backend. To be more specific, I need to check if a
> user that tries to authenticate with xauth exists in one of multiple
> backends and if his/her credentials are correct (e.g. simultaniously
> looking in a local DB, one or more LDAP directories and/or a RADIUS
> server).
>
> Is there any way to perform custom authentication and authorization?
>
> Sadly PAM is not an option/not available on this system.
>
> The ext-auth plugin is missing the password, so I can't use it to check
> if the user actually provided the correct credentials only if he/she
> exists and is authorized to connect.
>
> Best regards,
> Christoph Harder
>
> --
> TELCO TECH GmbH
> Niederlassung Berlin
> Mädewalder Weg 2
> 12621 Berlin
> Tel.: +49 30 565862610
> Web: www.telco-tech.de
> Amtsgericht Potsdam-Stadt HRB 55 79
> Geschäftsführung:
> Bernd Schulz
> Silke Schirmer
>


Re: [strongSwan] Windows 10 connects to StrongSwan but IP doesn't change

2019-04-02 Thread Felipe Arturo Polanco
Hi,

Do an ipconfig /all in windows and check that you have an 10.10.10.0/24 IP
in the output.

On Tue, Apr 2, 2019 at 6:03 AM Houman  wrote:

> Hey guys,
>
> I wonder if this email went through and someone has an idea why this is
> happening.
>
> Many Thanks,
> Houman
>
> On Fri, 29 Mar 2019 at 17:04, Houman  wrote:
>
>> Hello,
>>
>> Please help me with this, as I'm completely stuck.
>>
>> Windows 10 can connect to my StrongSwan server. But the IP address
>> doesn't change to the VPN. It still shows the local IP address. Accordingly
>> blocked websites remain blocked.
>>
>> config setup
>>   strictcrlpolicy=yes
>>   uniqueids=never
>> conn roadwarrior
>>   auto=add
>>   compress=no
>>   type=tunnel
>>   keyexchange=ikev2
>>   fragmentation=yes
>>   forceencaps=yes
>>   ike=aes256gcm16-prfsha256-ecp521,aes256-sha256-ecp384
>>   esp=aes256-sha1,3des-sha1!
>>   dpdaction=clear
>>   dpddelay=180s
>>   rekey=no
>>   left=%any
>>   leftid=@vpn-1.domain.net
>>   leftcert=cert.pem
>>   leftsendcert=always
>>   leftsubnet=0.0.0.0/0
>>   right=%any
>>   rightid=%any
>>   rightauth=eap-radius
>>   eap_identity=%any
>>   rightdns=208.67.222.222,208.67.220.220
>>   rightsourceip=10.10.10.0/24
>>   rightsendcert=never
>>
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[NET] received packet: from
>> 91.98.xxx.xxx[500] to 172.31.0.243[500] (632 bytes)
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[ENC] parsed IKE_SA_INIT request 0 [ SA
>> KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[IKE] received MS NT5 ISAKMPOAKLEY v9
>> vendor ID
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[IKE] received MS-Negotiation Discovery
>> Capable vendor ID
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[IKE] received Vid-Initial-Contact vendor
>> ID
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[ENC] received unknown vendor ID:
>> 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[IKE] 91.98.xxx.xxx is initiating an
>> IKE_SA
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[IKE] local host is behind NAT, sending
>> keep alives
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[IKE] remote host is behind NAT
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[ENC] generating IKE_SA_INIT response 0 [
>> SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(MULT_AUTH) ]
>>
>> Mar 29 16:50:45 vpn-1 charon: 08[NET] sending packet: from
>> 172.31.0.243[500] to 91.98.xxx.xxx[500] (448 bytes)
>>
>> Mar 29 16:50:45 vpn-1 charon: 09[NET] received packet: from
>> 91.98.xxx.xxx[4500] to 172.31.0.243[4500] (576 bytes)
>>
>> Mar 29 16:50:45 vpn-1 charon: 09[ENC] parsed IKE_AUTH request 1 [ EF(1/4)
>> ]
>>
>> Mar 29 16:50:45 vpn-1 charon: 09[ENC] received fragment #1 of 4, waiting
>> for complete IKE message
>>
>> Mar 29 16:50:45 vpn-1 charon: 10[NET] received packet: from
>> 91.98.xxx.xxx[4500] to 172.31.0.243[4500] (576 bytes)
>>
>> Mar 29 16:50:45 vpn-1 charon: 10[ENC] parsed IKE_AUTH request 1 [ EF(2/4)
>> ]
>>
>> Mar 29 16:50:45 vpn-1 charon: 10[ENC] received fragment #2 of 4, waiting
>> for complete IKE message
>>
>> Mar 29 16:50:45 vpn-1 charon: 12[NET] received packet: from
>> 91.98.xxx.xxx[4500] to 172.31.0.243[4500] (576 bytes)
>>
>> Mar 29 16:50:45 vpn-1 charon: 12[ENC] parsed IKE_AUTH request 1 [ EF(3/4)
>> ]
>>
>> Mar 29 16:50:45 vpn-1 charon: 12[ENC] received fragment #3 of 4, waiting
>> for complete IKE message
>>
>> Mar 29 16:50:45 vpn-1 charon: 11[NET] received packet: from
>> 91.98.xxx.xxx[4500] to 172.31.0.243[4500] (112 bytes)
>>
>> Mar 29 16:50:45 vpn-1 charon: 11[ENC] parsed IKE_AUTH request 1 [ EF(4/4)
>> ]
>>
>> Mar 29 16:50:45 vpn-1 charon: 11[ENC] received fragment #4 of 4,
>> reassembling fragmented IKE message
>>
>> Mar 29 16:50:45 vpn-1 charon: 11[ENC] parsed IKE_AUTH request 1 [ IDi
>> CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
>>
>> Mar 29 16:50:45 vpn-1 charon: 11[IKE] received 57 cert requests for an
>> unknown ca
>>
>> Mar 29 16:50:45 vpn-1 charon: 11[CFG] looking for peer configs matching
>> 172.31.0.243[%any]...91.98.xxx.xxx[192.168.1.104]
>>
>> Mar 29 16:50:45 vpn-1 charon: 11[CFG] selected peer config 'roadwarrior'
>>
>> Mar 29 16:50:45 vpn-1 ipsec[1051]: 05[ENC] parsed CREATE_CHILD_SA request
>> 15 [ SA No TSi TSr ]
>>
>> Mar 29 16:50:45 vpn-1 ipsec[1051]: 05[IKE] CHILD_SA roadwarrior{3}
>> established with SPIs ccadd085_i d57f9f2c_o and TS 0.0.0.0/0 ===
>> 10.10.10.1/32
>>
>> Mar 29 16:50:45 vpn-1 ipsec[1051]: 05[ENC] generating CREATE_CHILD_SA
>> response 15 [ SA No TSi TSr ]
>>
>> Mar 29 16:50:45 vpn-1 ipsec[1051]: 05[NET] sending packet: from
>> 172.31.0.243[4500] to 91.98.xxx.xxx[4500] (204 bytes)
>>
>> Mar 29 16:50:45 vpn-1 ipsec[1051]: 07[NET] received packet: from
>> 91.98.xxx.xxx[4500] to 172.31.0.243[4500] (76 bytes)
>>
>> Mar 29 16:50:45 vpn-1 ipsec[1051]: 07[ENC] parsed INFORMATIONAL request
>> 16 [ D ]
>>
>> Mar 29 16:50:45 vpn-1 ipsec[1051]: 07[IKE] received DELETE for ESP
>> CHILD_SA with SPI af63e684
>>
>> Mar 29 16:50:45 vpn-1 ipsec[1051]: 07[IKE] closing 

Re: [strongSwan] Transport mode - specific ports only

2019-03-06 Thread Felipe Arturo Polanco
Hi,

Check your DPD settings, I have seen that incorrect setting on this cause
multiple SAs to be created.

Thanks,

On Wed, Mar 6, 2019 at 5:57 AM James Masson 
wrote:

> Hi list,
>
> I've got a working configuration for a collection of servers using
> transport mode to encrypt only a subset of ports, using strongswan 5.7.2-1 .
>
> However, it seems suboptimal, because the servers are generating and
> deleting new SAs every few seconds - I presume for every client port <>
> server port pair ? The traffic on these ports is UDP, so there would be
> massive overhead in doing this.
>
> Logs/config/SAs -
> https://gist.github.com/james-masson/347bcdab80c93c83dfc68f111a5cb472
>
> Can anybody point out a flaw in or improvements to my config?
>
> To be clear, I'm after a config that does crypto negotiation once per IP
> pair, but only encrypts traffic to/from a particular set of ports.
>
> thanks
>
> James M
>
>


Re: [strongSwan] [EDIT] Traffic selection problems

2019-03-02 Thread Felipe Arturo Polanco
You are right in that, the virtual IPs sent to the initiators are available
in initiator.

If your setup is point to point and not roadwarrior, you can use a range
from .254-.254 and try it out, .253 will be fixed in responder. I can't
confirm if this works as I haven't tried it.

If you want to use a point to multipoint using multiples /30 links, please
don't do this, that is a lot of headache to manage.

Put a big /16 network and put that in the range of the responder, use a
roadwarrior configuration and make this an NBMA network.

OSPF should work fine with this setup and you free yourself from managing
virtual /30 networks that its only purpose is to satisfy a next-hop
requirement of a dynamic protocol.

I did this exact same setup but using BGP since it uses TCP unicast and
cloud firewalls play nice with that, OSPF is layer 4 so it may bring
trouble if you move to the cloud.


On Sat, Mar 2, 2019 at 7:00 PM Brian Topping 
wrote:

>
> On Mar 2, 2019, at 3:48 PM, Felipe Arturo Polanco <
> felipeapola...@gmail.com> wrote:
>
> Please recheck how you are getting the environment variables, those values
> are definitely there.
>
> Did you try the exact command I sent on my last email? Put that inside the
> temporary updown script, put the shebang on the top and make it
> executable, the output file will contain all environment variables
> including PLUTO variables.
>
>
> Yes, I definitely checked it again to be sure. The PLUTO_MY_SOURCEIP
> and PLUTO_MY_SOURCEIP4_1 variables are defined to one side of the tunnel on
> the dynamic side, but those variables are not even defined on the static
> side. What more, the correct value does not show up under any key.
>
> From there you can issue each of your commands manually after connection
> setup and see what specific command is not working.
>
> I know this works as I set this up for a client some time ago and we faced
> a similar situation.
>
>
> Thanks, I appreciate that. Sometimes it’s easy to overlook stuff like this
> and without really closely examining the feedback, one can miss an
> opportunity to solve the issue.
>
> If it were possible at this stage without PLUTO_MY_SOURCEIP, I could
> imagine something like a PLUTO_PEER_SOURCEIP being defined, then figure out
> the address that remains using the set difference of PLUTO_MY_CLIENT (which
> is set to the tunnel network address and netmask).
>
> On the dynamic side, PLUTO_MY_SOURCEIP is defined but PLUTO_PEER_SOURCEIP
> is not. On the static side, neither is defined. This says to me that there
> is something about the static side configuration that leads it to believe
> it should not be participating in virtual IP setup. But that’s just a hunch
> and I’ll dig through the sources some more to see if I can prove that out.
>


Re: [strongSwan] [EDIT] Traffic selection problems

2019-03-02 Thread Felipe Arturo Polanco
Please recheck how you are getting the environment variables, those values
are definitely there.

Did you try the exact command I sent on my last email? Put that inside the
temporary updown script, put the shebang on the top and make it executable,
the output file will contain all environment variables including PLUTO
variables.

>From there you can issue each of your commands manually after connection
setup and see what specific command is not working.

I know this works as I set this up for a client some time ago and we faced
a similar situation.

On Sat, Mar 2, 2019 at 6:08 PM Brian Topping 
wrote:

> Thanks Felipe! I had checked that out in the past and there are no values
> that are set that could be used in in the script for the same effect (the
> static side tunnel endpoint address).
>
> There are two things I am wondering at this point:
>
>
>1. Getting this working probably has something to do with the code in
>
> https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/sa/ike_sa.c;h=3d576a0e89a67b6e76e636ed744e88bdbec3a551;hb=HEAD#l948-979.
>As I have seen an error where “site-1-static-ip has both left- and
>rightsourceip, but IKE can negotiate one virtual IP only, ignoring local
>virtual IP”, I clearly need to specify the leftsourceip on the static side.
>But the IP is no longer virtual in that case. And when it is no longer
>virtual, the code at
>
> https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/updown/updown_listener.c;h=bbefd6a027ceca473da327939da2f70aced887c6;hb=HEAD#l182
>  never
>finds it.
>2. Alternatively, maybe I should drop this idea of using Strongswan
>setting up VTIs. Maybe Bird can deal with tunnels that do not have VTIs and
>I just don’t understand that construction.
>
>
> I am worried that I will also lose future compatibility with VTI-capable
> routers (like Cisco et al) if I go with #2. I don’t have any present need
> for doing so, but if I did, converting everything would be a lot of tears.
>
> It seems like what I am trying to do in #1 is not possible given that
> addresses pushed through the updown plugin can only read from IPs found in
> ike_sa_t->my_vips.
>
> Brian
>
> On Mar 2, 2019, at 8:22 AM, Felipe Arturo Polanco <
> felipeapola...@gmail.com> wrote:
>
> You can extract the env variables information by using the "set" command,
> use a temporary updown script that has the following "set > /tmp/output",
> after establishing the connection, check that output file both in initiator
> and responder and see if the values are as expected, if they are, try to
> reproduce the script by typing each command one by one in the console and
> see its behavior.
>
> Remember to disable the updown script in strongswan when running it
> manually.
>
> Sent from mobile.
>
> On Sat, Mar 2, 2019, 2:22 AM Brian Topping 
> wrote:
>
>> Hi Felipe,
>>
>> That use of `left|rightsubnet` was a huge help.
>>
>> In an effort to automate the address assignment for a larger network
>> (same theme as the OSPF), I’ve been using the `leftupdown` script in
>> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Connection-specific-VTI-Devices
>> .
>>
>> So I’ve updated it as shown:
>>
>> =
>> Dynamic:
>> conn site-2-dynamic-ip
>>
>>mark=%unique
>>
>> left=%defaultroute
>>
>>leftsourceip=%config4
>>
>> leftsubnet=10.10.0.0/22,10.9.255.252/30
>> leftfirewall=no
>>
>>leftupdown=/etc/strongswan.d/ipsec-vti.sh
>>right=st.at.ic.ip
>>
>> rightsubnet=10.10.4.0/22,10.9.255.252/30
>> rightid=%specific.example.com
>> auto=add
>>
>> Static:
>> conn site-1-static-ip
>>
>>mark=%unique
>>
>> left=st.at.ic.ip
>> leftsubnet=10.10.4.0/22,10.9.255.252/30
>> leftid=%specific.example.com
>> leftfirewall=no
>>
>>leftsourceip=10.9.255.253
>>leftupdown=/etc/strongswan/ipsec-vti.sh
>>
>> right=%any
>>
>>rightsourceip=10.9.255.254
>>
>> rightsubnet=10.10.0.0/22,10.9.255.252/30
>> auto=add
>> ===
>>
>>
>> With this configuration, I get full SA and IKE negotiation including TS
>> and dynamic side tunnel configuration:
>>
>> root@dynamic:/# ip a show vti1
>> 49: vti1@NONE:  mtu 1472 qdisc noqueue
>> state UNKNOWN group default qlen 1000
>> link/ipip dy.na.mi.cip peer st.at.ic.ip
>>
>> inet 10.9.255.254/32 scope global vti1
>>valid_lft forever preferred_lft forever
>>
>>
>> On the static side, I get an error from the script:
>>
>> 04[CHD] updown: /etc/strongswan/ipsec-vti.sh: line 15: PLUTO_MY_SOURCEIP:
>> unbound variable
>>
>>
>> I initially had the same problem on the dynamic side, but the addition of
>> `leftsourceip=%config4` and `rightsourceip` on the static side resolved
>> that.
>>
>> Is there something I am missing to avoid the "PLUTO_MY_SOURCEIP: unbound
>> variable” problem?
>>
>> Thanks so much for your insight!
>>
>
>


Re: [strongSwan] [EDIT] Traffic selection problems

2019-03-02 Thread Felipe Arturo Polanco
You can extract the env variables information by using the "set" command,
use a temporary updown script that has the following "set > /tmp/output",
after establishing the connection, check that output file both in initiator
and responder and see if the values are as expected, if they are, try to
reproduce the script by typing each command one by one in the console and
see its behavior.

Remember to disable the updown script in strongswan when running it
manually.

Sent from mobile.

On Sat, Mar 2, 2019, 2:22 AM Brian Topping  wrote:

> Hi Felipe,
>
> That use of `left|rightsubnet` was a huge help.
>
> In an effort to automate the address assignment for a larger network (same
> theme as the OSPF), I’ve been using the `leftupdown` script in
> https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Connection-specific-VTI-Devices
> .
>
> So I’ve updated it as shown:
>
> =
> Dynamic:
> conn site-2-dynamic-ip
>
>mark=%unique
>
> left=%defaultroute
>
>leftsourceip=%config4
>
> leftsubnet=10.10.0.0/22,10.9.255.252/30
> leftfirewall=no
>
>leftupdown=/etc/strongswan.d/ipsec-vti.sh
>right=st.at.ic.ip
>
> rightsubnet=10.10.4.0/22,10.9.255.252/30
> rightid=%specific.example.com
> auto=add
>
> Static:
> conn site-1-static-ip
>
>mark=%unique
>
> left=st.at.ic.ip
> leftsubnet=10.10.4.0/22,10.9.255.252/30
> leftid=%specific.example.com
> leftfirewall=no
>
>leftsourceip=10.9.255.253
>leftupdown=/etc/strongswan/ipsec-vti.sh
>
> right=%any
>
>rightsourceip=10.9.255.254
>
> rightsubnet=10.10.0.0/22,10.9.255.252/30
> auto=add
> ===
>
>
> With this configuration, I get full SA and IKE negotiation including TS
> and dynamic side tunnel configuration:
>
> root@dynamic:/# ip a show vti1
> 49: vti1@NONE:  mtu 1472 qdisc noqueue
> state UNKNOWN group default qlen 1000
> link/ipip dy.na.mi.cip peer st.at.ic.ip
>
> inet 10.9.255.254/32 scope global vti1
>valid_lft forever preferred_lft forever
>
>
> On the static side, I get an error from the script:
>
> 04[CHD] updown: /etc/strongswan/ipsec-vti.sh: line 15: PLUTO_MY_SOURCEIP:
> unbound variable
>
>
> I initially had the same problem on the dynamic side, but the addition of
> `leftsourceip=%config4` and `rightsourceip` on the static side resolved
> that.
>
> Is there something I am missing to avoid the "PLUTO_MY_SOURCEIP: unbound
> variable” problem?
>
> Thanks so much for your insight!
>


[strongSwan] How to terminate a connection using swanctl ike-id

2019-03-01 Thread Felipe Arturo Polanco
Hi,

I have a roadwarrior setup where users connect to a strongswan server.

Since we have one single connection defined in swantl.conf, how can we
terminate a specific connection?

I see this command available:
swanctl --terminate --ike-id 

How can I get the ID of a given IKE SA?

Thanks,


Re: [strongSwan] [EDIT] Traffic selection problems

2019-03-01 Thread Felipe Arturo Polanco
Hi Brian,

Please try this configuration:
=
Dynamic:
conn site-2-dynamic-ip
left=%defaultroute
leftsubnet=10.10.0.0/22,10.9.255.252/30
leftfirewall=no
right=dy.na.mi.cip
rightsubnet=10.10.4.0/22,10.9.255.252/30
rightid=%specific.example.com
auto=add

Static:
conn site-1-static-ip
left=st.at.ic.ip
leftsubnet=10.10.4.0/22,10.9.255.252/30
leftid=%specific.example.com
leftfirewall=no
right=%any
rightsubnet=10.10.0.0/22,10.9.255.252/30
auto=add
===


Two things to observe:
In Initiator:
ip address add 10.9.255.253/30 dev vti
ip route add 10.10.4.0/22 dev vti src 10.9.255.253 #for locally generated
packets sent to 10.10.4.0/22 to have source as 10.9.255.253
OR
ip route add 10.10.4.0/22 dev vti src 10.10.0.1 #for locally generated
packets sent to 10.10.4.0/22 to have source as 10.10.0.1

Apply the same logic on the responder by replacing the destination network
and the source IP

Also

OSPF uses multicast for default operation in Ethernet, remember to change
this link to Point to Point so it uses unicast.

Let us know how it goes.

Thanks,

On Thu, Feb 28, 2019 at 7:51 PM Brian Topping 
wrote:

> Hi Felipe, thank you for your consideration of this. It took me a bit to
> create a diagram:
>
>
>  10.10.0.0/22 10.10.4.0/22
>   ^ ^
>   v v
>+---++---+
>|  Initiator||   Responder   |
>|---||---|
>|10.9.255.253/30| <- - - -VTI - - - ->|
> 10.9.255.254/30| 
>+---++---+
>  ^  ^
>  v  v
> ini.tia.tor.ip  < Internet >  res.pon.der.ip
>
> From the bottom, the internet connection between the initiator and
> responder, a PtP VTI between the the two nodes and in turn, the two /22
> networks that I want to connect through the VTI as native routing between
> networks (hence the VTI interfaces on each node). The initiator public IP
> is dynamic.
>
> The reason for not doing straight tunneling between the two /22 networks
> is OSPF discovery of interfaces, typical routing daemons can only see
> interfaces to add discovery over (ie “vti*”). As the network grows, the
> routing daemons will self-discover for optimal backbone routing.
>
> Apologies that I didn’t get deeper into that previously! Does it help?
>


Re: [strongSwan] [EDIT] Traffic selection problems

2019-02-28 Thread Felipe Arturo Polanco
Hi Brian,

Your traffic selectors look strange, left implies the source IP XFRM will
see and right implies the destination IP XFRM will see in order to know if
it has to transform and encrypt that IP packet.

Can you tell us the existing subnets in both sites?
Site 1 with static IP has x.x.x.x subnet
Site 2 with dynamic IP has x.x.x.x subnet

Also, what are those two /30 networks for? is that needed to go inside the
tunnel as well?

On Thu, Feb 28, 2019 at 5:10 AM Brian Topping 
wrote:

> > VTI devices won't change anything.  You can't use transport mode with
> > any IPs other than those of the endpoints (i.e. it doesn't work with
> > virtual IPs or arbitrary subnets - you have to use tunnel mode for that).
>
> Got it, thanks Tobias. But the logs say `06[IKE] not using transport mode,
> not host-to-host` and the SADB modes are all `tunnel`, so the stack appears
> to have made up for my error.
>
> Or has it?
>


Re: [strongSwan] Problem: "unable to install policy -the same policy for reqid XXXX exists "

2018-12-01 Thread Felipe Arturo Polanco
Hi Sven,

You can try to manually specify the reqid in your ipsec.conf file, as per
your log messages a second CHILD_SA is trying to install the same traffic
selectors as a previous CHILD_SA.

Also I believe there is a 'unique=yes' option that should reuse the same
previously assigned reqid and prevent the creation of multiple CHILD_SA
that may conflict with each other.





On Fri, Nov 30, 2018 at 5:14 PM Sven Anders  wrote:

> Am 28.11.18 um 11:31 schrieb Tobias Brunner:
> > Hi Sven,
> >
> >> So the problem is known?
> >
> > Not really, but maybe something changed that avoids the issue, and I
> > don't particularly fancy debugging old versions.
> >
> >> Which version should I use at least. Will 5.6.3 be enough or
> >> should I use 5.7.1 instead?
> >
> > If you consider updating, use the latest.
>
> I will do it, but it will take some time until we can deploy it
> to the customer...
>
> >> There are many request and the log file is very long.
> >
> > So?
> >
> >> What kind of message do you expect or what should I search for?
> >
> > For instance, messages around refcount changes of the policies.  You can
> > also post it somewhere for us to have a look at.
>
> Thank you,
>
> I will send you a link to download it. If anybody want the log output too,
> to analyse
> it, I will send you the link.
>
>
> Regards
>  Sven Anders
>
> --
>  Sven Anders  () UTF-8 Ribbon Campaign
>  /\ Support plain text
> e-mail
>  ANDURAS intranet security AG
>  Messestrasse 3 - 94036 Passau - Germany
>  Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90
> 50-55
>
> Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety.
>   - Benjamin Franklin
>
>


[strongSwan] Problem with mark_out on re-marked packets

2018-10-22 Thread Felipe Arturo Polanco
Hi,

We are facing a strange issue where if a packet is re-marked by
iptables Strongswan doesn't allow it to go out to the tunnel.

example:
myvpn1 (site to site)
mark_in = 1
mark_out = 1
local_ts = 0.0.0.0/0
remote_ts = 10.0.0.0/8

myvpn2 (site to site)
mark_in = 2
mark_out = 2
local_ts=0.0.0.0/0
remote_ts=172.16.0.0/24

The traffic is to be forwarded between myvpn1 and myvpn2: Src 10.0.0.1 dst
172.16.0.1
We mark the traffic coming from myvpn1 with :
iptables -t mangle -I PREROUTING -s a.a.a.a/32 -j MARK --set-xmark 1
a.a.a.a is the public IP of myvpn1.

That way we satisfy the condition of mark_in for myvpn1.
We see the packet coming in as the 'in' counter increases and TCPdump shows
the decapsulated packet.

We have this other rule in iptables:
iptables -t mangle -I POSTROUTING -d 172.16.0.0/24 -j MARK --set-xmark 2
With this we mark all traffic destined to 172.16.0.0/24 with a mark of 2.

The problem is that the packets remarked from 1 to 2 are not going through
the tunnel at all, the 'out' counter of myvpn2 doesn't increase.

We do see the packet being correctly remarked to '2' using Iptables trace
in the raw table.

If we change mark_out to 1 in myvpn2 and remove the set-xmark 2 from
iptables it works fine and the packet gets forwarded.

Any idea what could be the trouble in here?

Thanks,


[strongSwan] How to override traffic selectors in swanctl

2018-06-13 Thread Felipe Arturo Polanco
Hi,

I would like to dynamically create connections to multiple IPSec peers
based on a child template.

One missing piece I still have is how to override the traffic selector of a
child connection declared in swanctl.conf

My child connection has this:
remote_ts = dynamic[udp/4789],dynamic[icmp]

I would like to override this local_ts whenever I run:
swanctl --initiate --child myipsec1 --source  --remote 

I would like to add a specific subnet that is accessible through my peer,
the equivalent ts would be like this:
remote_ts = dynamic[udp/4789],dynamic[icmp],172.16.35.0/24

I do have dozens of peers and each has a specific subnet behind them.

Is there any way of specifying/modifying the traffic selector of a
connection child to achieve this?

Thanks,


[strongSwan] iPhone iOS devices disconnecting when screen if off.

2017-06-14 Thread Felipe Arturo Polanco
Hi,

We are facing a problem with our Strongswan 5.4 IKEv1 xAUTH with PSK server.

Basically we can get all the devices login fine and get their IPs but when
the iphone turn off the screen, after a few seconds the connection drops.

I have many servers with this issue and only happens to devices when they
go to sleep, in Android devices it works fine.

Here is our ipsec.conf:

config setup
cachecrls=yes
uniqueids=yes
charondebug="cfg 2, chd 2, esp 2, ike 2, knl 2, mgr 2, net 2"

conn ios
keyexchange=ikev1
authby=xauthpsk
xauth=server
leftsubnet=0.0.0.0/0
leftfirewall=yes
lefthostaccess=yes
right=%any
rightsourceip=192.168.47.1/24
rightdns=8.8.8.8
auto=add

We appreciate any help on this.

Thanks,


[strongSwan] Roadwarriors not able to access remote LAN

2017-05-13 Thread Felipe Arturo Polanco
Hi,

I have setup Strongswan 5 to connect iphone devices to a remote VPN server
with a LAN behind it, all traffic is encrypted.

Sadly I haven't been able to make the VPN clients access the internal LAN
without putting a masquerade rule in the LAN interface of the server, since
I need to log the IP of each client on the internal DNS this has been a
blockroad.

I'm kind of new to Strongswan so maybe I missed something.

If I put a public DNS server like 8.8.8.8 in rightdns clients can access
it, if I put my local DNS it won't work unless I masquerade the out
interface.

Tcpdump shows a packet from the VPN subnet as source going to the DNS
server as destination but the packet never arrives at the DNS.

I already added static route into the DNS routing table for the VPN subnet.

Here is my ipsec.conf in the VPN server.

config setup
cachecrls=yes
uniqueids=yes
charondebug="cfg 2, chd 2, esp 2, ike 2, knl 2, mgr 2, net 2"

conn ios
keyexchange=ikev1
authby=xauthpsk
xauth=server
left=%defaultroute
leftsubnet=0.0.0.0/0
leftfirewall=yes
lefthostaccess=yes
right=%any
rightsubnet=192.168.47.0/24
rightsourceip=192.168.47.1/24
rightdns=172.16.10.2
righthostaccess=yes
auto=add


strongswan.conf

charon {
load_modular = yes
plugins {

include strongswan.d/charon/*.conf
}
}

include strongswan.d/*.conf


iptables-save

root@SSvpn01:~# iptables-save
# Generated by iptables-save v1.6.0 on Sun May 14 00:18:25 2017
*filter
:INPUT ACCEPT [5741:1711308]
:FORWARD ACCEPT [10:1033]
:OUTPUT ACCEPT [5709:1646619]
COMMIT
# Completed on Sun May 14 00:18:25 2017
# Generated by iptables-save v1.6.0 on Sun May 14 00:18:25 2017
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o eth1 -j MASQUERADE  <- this makes all clients IP appear
as if they came from the server
COMMIT
# Completed on Sun May 14 00:18:25 2017

Any help would be appreciated.