Seem to suffer the same issues on the VM
ens18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.55.88.150 netmask 255.255.255.0 broadcast 10.55.88.255
inet6 fe80::a841:28ff:fe0a:af0d prefixlen 64 scopeid 0x20<link>
ether aa:41:28:0a:af:0d txqueuelen 1000 (Ethernet)
RX packets 590 bytes 331687 (331.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 304 bytes 56308 (56.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
gre1: flags=193<UP,RUNNING,NOARP> mtu 1472
inet 172.16.0.20 netmask 255.255.255.255
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen
1000 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
TCPDump:
root@hub2-nhrp:/home/jon# tcpdump -i ens18 -n not port 22 and not port 53
and host 10.55.88.150
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens18, link-type EN10MB (Ethernet), capture size 262144 bytes
19:00:01.381341 IP 10.55.88.150.37026 > 172.16.0.1.179: Flags [S], seq
55986250, win 29200, options [mss 1460,sackOK,TS val 439321532 ecr
0,nop,wscale 7], length 0
19:00:02.413007 IP 10.55.88.150.37026 > 172.16.0.1.179: Flags [S], seq
55986250, win 29200, options [mss 1460,sackOK,TS val 439321790 ecr
0,nop,wscale 7], length 0
19:00:03.430560 IP 10.55.88.150.34187 > 91.189.91.157.123: NTPv4, Client,
length 48
19:00:03.517827 IP 91.189.91.157.123 > 10.55.88.150.34187: NTPv4, Server,
length 48
19:00:04.429125 IP 10.55.88.150.37026 > 172.16.0.1.179: Flags [S], seq
55986250, win 29200, options [mss 1460,sackOK,TS val 439322294 ecr
0,nop,wscale 7], length 0
19:00:08.533084 ARP, Request who-has 10.55.88.150 tell 10.55.88.1, length 28
19:00:08.533095 ARP, Reply 10.55.88.150 is-at aa:41:28:0a:af:0d, length 28
19:00:08.685052 IP 10.55.88.150.37026 > 172.16.0.1.179: Flags [S], seq
55986250, win 29200, options [mss 1460,sackOK,TS val 439323358 ecr
0,nop,wscale 7], length 0
19:00:16.877014 IP 10.55.88.150.37026 > 172.16.0.1.179: Flags [S], seq
55986250, win 29200, options [mss 1460,sackOK,TS val 439325406 ecr
0,nop,wscale 7], length 0
Swanctl.conf
^Croot@hub2-nhrp:/home/jon# cat /etc/swanctl/swanctl.conf
connections {
dmvpn {
version = 2 # enable IKEv2
pull = no # IKEv1 only. Push
enabled. IKEv2 does not support pull.
mobike = no # disable support for
mobile clients tunnel migration
dpd_delay = 15 # Interval to check the
liveness of a peer if not traffic has passed
dpd_timeout = 30 # IKEv1 only
fragmentation = yes # NOTE: has recently
been added. docs are outdated.
unique = replace # replace connection if
it already exists
rekey_time = 4h # rekey is by default
already 4h
reauth_time = 13h # re authenticate ipsec
tunnel
proposals = aes128-sha256-ecp384 # docs say default is
considered safe and has good interoperability
local {
auth = psk # a private key associated
to a usable certificate
id = hub2@mynetwork.cloud # IKE
identity which should be included in the certificate. ie fqdn
}
remote {
auth = psk
id = hub6@mynetwork.cloud #
Authentication to expect from remote
}
children { # what is the
difference between remote and children? local and remote is only to specify
authentication?
dmvpn {
esp_proposals = aes128-sha256-ecp384 #
docs say default is considered safe and has good interoperability
local_ts = dynamic[gre] #
traffic selectors, dynamic to use outer address of virtual ip. restrict to
GRE protocol
remote_ts = dynamic[gre] #
traffic selectors, dynamic to use outer address of virtual ip. restrict to
GRE protocol
inactivity = 90m #
close CHILD_SA after inactivity
rekey_time = 100m #
Time to schedule CHILD_SA rekeying
mode = transport #
IPsec Mode to establish CHILD_SA with
dpd_action = clear #
default is clear
reqid = 1 # why
not use dynamic reqids, allocated incrementally?
}
}
}
}
secrets {
dmvpn-secret {
id = hub6@mynetwork.cloud
secret = "password123"
}
}
On Sun, 30 Jul 2017 at 18:31 M87tech [Jon] <m87t...@gmail.com> wrote:
> Could it be anything to do with NFLOG and the iptables rules?
>
> Does this require any special kernel module that I may not have access to
> in LXD?
>
> Cheers,
> Jon.
>
> On Sun, 30 Jul 2017 at 18:26 M87tech [Jon] <m87t...@gmail.com> wrote:
>
>> Hi Timo
>>
>> It's your version compiled from source, I assume that is the correct
>> patched one?
>>
>> git clone -b tteras-release git://
>> git.alpinelinux.org/user/tteras/strongswan
>>
>> ./configure --enable-systemd --enable-swanctl --with-systemd
>> systemunitdir=/etc/systemd/system/multi-user.target.wants --prefix=/usr
>> --sysconfdir=/etc
>>
>> make
>> make install
>>
>> Ubuntu version is 17.04 but also tried with 16.04 and everything was the
>> same.
>>
>> Unsure why there are no TX counters on GRE1 which is a bad sign.
>>
>> I'm about to test on a VM to see if there is any difference vs the above
>> which was done in an privileged LXD container.
>>
>> And yeah can't se anything related to ipsec happening, nothing in "ipsec
>> status" and no 500 or 4500 udp packets, just BGP tries to peer but sourcing
>> from ETH0 and not GRE1 which is weird.
>>
>> Cheers,
>> Jon.
>>
>>
>>
>>
>> On Sun, 30 Jul 2017 at 15:56 Timo Teras <timo.te...@iki.fi> wrote:
>>
>>> On Sun, 30 Jul 2017 09:30:13 +0000
>>> "M87tech [Jon]" <m87t...@gmail.com> wrote:
>>>
>>> > Hi,
>>> >
>>> > I'm trying to get a dmvpn testbed up and running using privileged LXD
>>> > containers.
>>> >
>>> > So far I'm stuck with an error message that looks to be related to the
>>> > interfaces some how, the logs show its resolved the hub then waiting
>>> > for a link:
>>> >
>>> > 2017/07/30 09:17:22.84 NHRP: gre1: bound to eth0
>>> > 2017/07/30 09:17:23.75 NHRP: VICI: Connected
>>> > 2017/07/30 09:17:23.75 NHRP: VICI: Message 5, 1 bytes
>>> > 2017/07/30 09:17:23.75 NHRP: VICI: Message 5, 1 bytes
>>> > 2017/07/30 09:17:23.75 NHRP: VICI: Message 5, 1 bytes
>>> > 2017/07/30 09:17:23.75 NHRP: VICI: Message 5, 1 bytes
>>> > 2017/07/30 09:17:23.75 NHRP: VICI: Message 1, 1 bytes
>>> > 2017/07/30 09:17:23.84 NHRP: [0x23e4f30] Resolving
>>> > 'hub6.wizznet.co.uk' 2017/07/30 09:17:23.84 NHRP: Netlink: Received
>>> > msg_type 28, msg_flags 0 2017/07/30 09:17:23.86 NHRP: [0x23e4f30]
>>> > Resolved with 1 results 2017/07/30 09:17:23.91 NHRP: NHS: Waiting
>>> > link for 51.15.49.245 2017/07/30 09:17:34.06 NHRP: Netlink-log:
>>> > Received msg_type 2, msg_flags 0 2017/07/30 09:17:34.06 NHRP: NHS:
>>> > Flush timer for 51.15.49.245 2017/07/30 09:17:34.08 NHRP: NHS:
>>> > Waiting link for 51.15.49.245 2017/07/30 09:17:36.08 NHRP:
>>> > vici_reconnect: failure connecting VICI socket: Connection refused
>>>
>>> VICI reconnect is unusual? Did you restart strongSwan? Is the
>>> strongSwan you are running patched with the required changes?
>>>
>>> Details on the above patches should be in frr's nhrpd/README.nhrp
>>>
>>> > 2017/07/30 09:17:38.08 NHRP: VICI: Connected
>>> > 2017/07/30 09:17:38.08 NHRP: VICI: Message 5, 1 bytes
>>> > 2017/07/30 09:17:38.08 NHRP: VICI: Message 5, 1 bytes
>>> > 2017/07/30 09:17:38.08 NHRP: VICI: Message 5, 1 bytes
>>> > 2017/07/30 09:17:38.08 NHRP: VICI: Message 5, 1 bytes
>>> > 2017/07/30 09:17:38.08 NHRP: VICI: Message 1, 1 bytes
>>> > 2017/07/30 09:17:44.72 NHRP: Netlink: Received msg_type 28, msg_flags
>>> > 0
>>> >
>>> > Particular message "msg_type 28" keeps repeating on and on.
>>>
>>> That is pretty normal.
>>>
>>> > I don't see any TX traffic counters on interface gre1
>>> >
>>> > after a tcpdump BGP packets are sourcing from eth0 which doesn't seem
>>> > right at all so it looks like nhrp isn't using the gre1 interface.
>>> >
>>> > I'm wondering if this is an issue with the fact that it is in a
>>> > container vs a normal machine or VM.
>>> >
>>> > the container is privileged and unconfined so has access to tunnel
>>> > interfaces (in theory!)
>>> > I don't see any ipsec packets on 500 or 4500 udp, not a peep. It
>>> > looks like its not even attempting to use the gre1 interface and thus
>>> > no ipsec? Just unencrypted bgp packets from eth0 with destination of
>>> > the hub.
>>>
>>> First thing happening should be the IKE SA being established. So if you
>>> don't see port 500/4500 traffic, then integration to strongSwan is not
>>> working right.
>>>
>>> > Any help or pointers would be much appreciated!
>>>
>>> Which strongSwan you have?
>>>
>>> Timo
>>>
>> --
>> M87 TECH
>> Jon Clayton
>>
>> --
> M87 TECH
> Jon Clayton
>
> --
M87 TECH
Jon Clayton
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
opennhrp-devel mailing list
opennhrp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opennhrp-devel
