Re: [Swan] one way ping
Yes the data goes over proto 50, but if NAT is detected the proto 50 is encapsulated into a udp port 4500 packet Sent from my phone > On Aug 31, 2018, at 11:16, John Crisp wrote: > >> On 31/08/18 01:18, Paul Wouters wrote: >> If there is no NAT you need to open protocol 50 ESP (not port, protocol) >> > > Thanks Paul > > OK.. I know I have that open on the server firewall but can't > remember seeing an option on the cloud providers one. > > Is that because the negotiation is over 500/4500 but the data itself > flows on protocol 50 ? > > Just curious :-) > > ___ > Swan mailing list > Swan@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
On 31/08/18 01:18, Paul Wouters wrote: > If there is no NAT you need to open protocol 50 ESP (not port, protocol) > Thanks Paul OK.. I know I have that open on the server firewall but can't remember seeing an option on the cloud providers one. Is that because the negotiation is over 500/4500 but the data itself flows on protocol 50 ? Just curious :-) signature.asc Description: OpenPGP digital signature ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
If there is no NAT you need to open protocol 50 ESP (not port, protocol) Sent from my phone > On Aug 30, 2018, at 18:59, John Crisp wrote: > >> On 28/08/18 21:56, Paul Wouters wrote: >> >> >> could this be due to a RELATED iptables rules that only allows replies ? >> > > > Just found it. I have a Firewall on the hosting at vultr where the two > VMs are. It has the following basic firewall rules and each server has > the same rule set applied (they have their own firewalls too) > > accept ICMP - 0.0.0.0/0 > accept TCP 80 0.0.0.0/0 > accept TCP 0.0.0.0/0 > accept TCP 4430.0.0.0/0 > accept TCP 4650.0.0.0/0 > accept UDP 5000.0.0.0/0 > accept UDP 4500 0.0.0.0/0 > drop any 0-65535 0.0.0.0/0 > > For whatever good reason when I removed the servers from my hosting > providers firewall group the pings suddenly flowed. ! > > Not sure what else I'd need to open to let pings across the VPN through!!! > > The servers own firewall seems to be quite happy with the same rules as > above. > > ___ > Swan mailing list > Swan@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
On 28/08/18 21:56, Paul Wouters wrote: > > could this be due to a RELATED iptables rules that only allows replies ? > Just found it. I have a Firewall on the hosting at vultr where the two VMs are. It has the following basic firewall rules and each server has the same rule set applied (they have their own firewalls too) accept ICMP - 0.0.0.0/0 accept TCP 80 0.0.0.0/0 accept TCP 0.0.0.0/0 accept TCP 4430.0.0.0/0 accept TCP 4650.0.0.0/0 accept UDP 5000.0.0.0/0 accept UDP 4500 0.0.0.0/0 drop any 0-65535 0.0.0.0/0 For whatever good reason when I removed the servers from my hosting providers firewall group the pings suddenly flowed. ! Not sure what else I'd need to open to let pings across the VPN through!!! The servers own firewall seems to be quite happy with the same rules as above. signature.asc Description: OpenPGP digital signature ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
On Tue, 24 Jul 2018, John Crisp wrote: Well, I swapped the dummy adaptor for a proper interface with the virt_io driver just to be sure. However, ping was working even with the dummy adaptor, so logically the networking was actually functioning. You can ping happily from Libre -> Endian as soon as the tunnel is up. You cannot ping from Endian -> Libre unless you have pinged the other way first. could this be due to a RELATED iptables rules that only allows replies ? Paul ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
On 20/07/18 01:43, John Crisp wrote:
> I'm sure i have had this before, and I found a solution, but beating my
> head against a wall.
>
> I have a Endian <-> Libre 3.23 v2 ipsec tunnel
>
> It uses certificates and the tunnel comes up fine.
>
Well, I swapped the dummy adaptor for a proper interface with the
virt_io driver just to be sure. However, ping was working even with the
dummy adaptor, so logically the networking was actually functioning.
You can ping happily from Libre -> Endian as soon as the tunnel is up.
You cannot ping from Endian -> Libre unless you have pinged the other
way first.
It wouldn't be so bad if it was in reverse as I rarely need to get from
Libre back to Endian !!
I have tried swapping the 'Start' ends but that doesn't fix it. Updated
to 3.25 and that didn't do it either.
I can only presume it is a routing or firewall issue somewhere but I
just can't fathom how to figure out which. As previously mentioned I
have 3 other boxes with identical setups (now that I have swapped to the
virt_io driver) that all work perfectly.
Here is some config stuff. I'm not that clever on the debugging of this
:-( Damn annoying as the certs always used to be the tricky bit but I
seem to have go that sorted easily now!
Any thoughts on how I can try and trace where the issue is appreciated.
Been banging my head against the wall for days.
1.1.1.1 Endian home IP
1.1.1.250 Endian Gateway IP
6.6.6.6 Cloud server IP
Libreswan
config setup
protostack=netkey
plutodebug=none
#klipsdebug=none
plutostderrlog=/var/log/pluto/pluto.log
dumpdir=/var/run/pluto/
virtual_private=%v4:192.168.10.0/24
include /etc/ipsec.d/ipsec.conf
conn server2ToHomeMain
type=tunnel
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
leftcert="webRegi"
rightcert="1.1.1.1"
auto=add
ikev2=insist
ike=aes256-sha2;dh14
phase2alg=aes256-sha2;dh14
encapsulation=no
keyingtries=0
ikelifetime=3600s
salifetime=28800s
dpdaction=restart
dpddelay=30
dpdtimeout=10
pfs=yes
left=%defaultroute
leftid=%fromcert
leftsourceip=192.168.81.1
leftsubnet=192.168.81.0/24
right=1.1.1.1
rightid=%fromcert
rightsubnet=192.168.10.0/24
Endian
conn server2ToHomeMain
dpdaction=restart
left=1.1.1.1
leftnexthop=1.1.1.250
leftsubnet=192.168.10.0/24
right=6.6.6.6
rightsubnet=192.168.81.0/24
leftcert=1.1.1.1cert.pem
rightcert=webRegicert.pem
authby=pubkey
leftsigkey=%cert
rightsigkey=%cert
leftid="@Endian"
rightid="@www-server2-Home"
ikelifetime=1h
keylife=8h
ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256-modp2048
auto=start
keyexchange=ikev2
Libre log
Jul 24 00:26:06.988354: loading secrets from "/etc/ipsec.secrets"
Jul 24 00:26:06.988436: loading secrets from "/etc/ipsec.d/ipsec.secrets"
Jul 24 00:26:33.657476: packet from 1.1.1.1:500: local IKE proposals for
server2ToHomeMain (IKE SA responder matching remote proposals):
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
Jul 24 00:26:33.657620: packet from 1.1.1.1:500: proposal
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
chosen from remote proposals
1:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match]
2:IKE:ENCR=AES_CBC_128;ENCR=AES_CBC_192;ENCR=AES_CBC_256;ENCR=3DES;INTEG=AES_XCBC_96;INTEG=AES_CMAC_96;INTEG=HMAC_SHA1_96;INTEG=HMAC_MD5_96;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_512_256;PRF=AES128_XCBC;PRF=AES128_CMAC;PRF=HMAC_SHA1;PRF=HMAC_MD5;PRF=HMAC_SHA2_256;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_512;DH=MODP2048;DH=DH23;DH=DH24;DH=MODP1536;DH=MODP3072;DH=MODP4096;DH=MODP8192;DH=MODP1024;DH=DH22
Jul 24 00:26:33.665521: "server2ToHomeMain" #1: STATE_PARENT_R1:
received v2I1, sent v2R1 {auth=IKEv2 cipher=aes_256 integ=sha256_128
prf=sha2_256 group=MODP2048}
Jul 24 00:26:33.835436: "server2ToHomeMain" #1: certificate verified OK:
CN=1.1.1.1,O=efw,C=IT
Jul 24 00:26:33.835713: "server2ToHomeMain" #1: IKEv2 mode peer ID is
ID_DER_ASN1_DN: 'C=IT, O=efw, CN=1.1.1.1'
Jul 24 00:26:33.835846: "server2ToHomeMain" #1: Authenticated using RSA
Jul 24 00:26:33.853754: "server2ToHomeMain" #1: local ESP/AH proposals
for server2ToHomeMain (IKE SA responder matching remote ESP/AH
proposals):
1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=NONE;ESN=DISABLED
Jul 24 00:26:33.853871: "server2ToHomeMain" #1: proposal
1:ESP:SPI=cefcc396;ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED
chosen from remote proposals
1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match]
2:ESP:ENCR=AES_CBC_128;ENCR=AES_CBC_192;ENCR=AES_CBC_256;ENCR=3DES;ENCR=BLOWFISH(UNUSED)_256;INTEG=HMAC_SHA1_96;INTEG=AES_XCBC_96;INTEG=HMAC_MD5_96;ESN=DISABLED
Jul 24 00:26:33.853979: "server2ToHomeMain" #1: received unsupported
NOTIFY v2N_ADDITIONAL_IP4_ADDRESS
Jul 24 00:26:33.854007: "server2ToHomeMain" #1: received
Re: [Swan] one way ping
On 20/07/18 15:08, Paul Wouters wrote: > Not too much to add but in the past I know that dummy interfaces could eat > packets. > As a further follow up two things seemed to affect it. One was the use of a 'dummy0' address. As the machine was on a VM I gave it a 'Private' adaptor, which it then detected and added with a virt_io device. However, that still didn't seem to work. So I looked at the networking. I had decided to use DHCP to configure the external device. This gave the following Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.169.254 222.250.226.1 255.255.255.255 UGH 0 0 0 eth0 10.0.0.0 222.250.226.1 255.255.255.0 UG 0 0 0 eth0 192.168.81.0 * 255.255.255.0 U 0 0 0 eth1 192.168.10.0 222.250.226.1 255.255.255.0 UG 0 0 0 eth0 222.250.226.0 * 255.255.254.0 U 0 0 0 eth0 default 222.250.226.1 0.0.0.0 UG 0 0 0 eth0 inet addr:222.250.227.83 Bcast:222.250.227.255 Mask:255.255.254.0 (real IP obfuscated slightly) I have a feeling the 'Destination' may have caused the issue, though I am not 100% on this. I changed the IP to static and now have this, and it works Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 222.250.226.1 * 255.255.255.255 UH 0 0 0 eth0 10.0.0.0 222.250.226.1 255.255.255.0 UG 0 0 0 eth0 192.168.81.0 * 255.255.255.0 U 0 0 0 eth1 192.168.10.0 222.250.226.1 255.255.255.0 UG 0 0 0 eth0 222.250.226.0 * 255.255.254.0 U 0 0 0 eth0 default 222.250.226.1 0.0.0.0 UG 0 0 0 eth0 So a combination of driver/port and IP addressing seem to be at the heart of it. I am wondering if there is a setting in ipsec that may have got round this (the addresing, not the dummy0 issue)? nexthop perhaps? signature.asc Description: OpenPGP digital signature ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
Not too much to add but in the past I know that dummy interfaces could eat packets. Paul Sent from my phone > On Jul 20, 2018, at 07:17, John Crisp wrote: > >> On 20/07/18 11:36, John Crisp wrote: >> >> I have reason to suspect that this may be the cause of my problems. >> > > Hmmm - maybe not, because logically it is working because once I ping > from Libre -> Endian I can then ping from Endian -> Libre indicating > that the underlying networking is functioning. > > Thank god it is Friday. > > ___ > Swan mailing list > Swan@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
On 20/07/18 11:36, John Crisp wrote: > > I have reason to suspect that this may be the cause of my problems. > Hmmm - maybe not, because logically it is working because once I ping from Libre -> Endian I can then ping from Endian -> Libre indicating that the underlying networking is functioning. Thank god it is Friday. signature.asc Description: OpenPGP digital signature ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
On 20/07/18 09:51, Roberto Suárez Soto wrote:
> El 20/07/18 a las 01:43, John Crisp escribió:
>> However, once up I can only ping from the Libre end -> Endian.
>>
>> Once a ping has been sent, magically I can ping from the Endian back to
>> Libre
>
> I've seen this happen when the firewall at one end ("Libre", in this
> case) doesn't allow incoming IPSec connections, or maybe just ESP
> traffic (or, if encapsulated, 4500/udp). It doesn't work when initiating
> the connection (i.e., ping) from the other side, but when you do it from
> the Libre side, the replies get into the "related" state and are
> allowed. If this is the case, you may see the dropped packets in Libre's
> logs.
>
> My 2¢, anyway.
>
Thanks !
I was checking in the cold hard light of day after a decent nights sleep
and noticed there is one significant difference I had missed.
The working versions are Proxmox VMs with virtual ethernet adaptors
using a virtio_net driver on both the 'real' outside interface and the
'dummy' internal one. That puts the machine in server-gateway mode so
the firewalling works etc etc
But the two non working machines have a ethernet dummy adaptor set up on
the 'internal' interface and that has no driver.
I have reason to suspect that this may be the cause of my problems.
I'll post back once I test a bit more
B. Rgds
John
signature.asc
Description: OpenPGP digital signature
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] one way ping
El 20/07/18 a las 01:43, John Crisp escribió:
> However, once up I can only ping from the Libre end -> Endian.
>
> Once a ping has been sent, magically I can ping from the Endian back to
> Libre
I've seen this happen when the firewall at one end ("Libre", in this
case) doesn't allow incoming IPSec connections, or maybe just ESP
traffic (or, if encapsulated, 4500/udp). It doesn't work when initiating
the connection (i.e., ping) from the other side, but when you do it from
the Libre side, the replies get into the "related" state and are
allowed. If this is the case, you may see the dropped packets in Libre's
logs.
My 2¢, anyway.
Greetings,
--
Roberto Suárez Soto
Allenta Consulting (+34 881 922 600)
ISO 9001, ISO 14001, ISO 27001, EMAS
Privacidad / Privacy
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
