Am Fri, 10 Jan 2020 14:31:40 +0100 schrieb Janne Johansson <[email protected]>:
> Den fre 10 jan. 2020 kl 13:58 skrev list <[email protected]>: > > > > > There's a tunnel between Server A and Server B. Server A is a > > > > standalone machine trying to reach over the VPN tunnel to a host > > > > (10.0.1.50) that is located in a subnet of Server B. Setup is > > > > the > > > > > > I appreciate the directions but after defining the exact same rules > > as in the Tutorial (-> OpenBSD as roadwarrior) I still see the same > > errors. This time I implemented it in a test environment. > > Two testmachines: > > Machine A wants to route all it's traffic through machine B. > > > > Machine A (192.168.22.222: > > $ cat /etc/iked.conf > > ikev2 'roadwarrior' active esp \ > > from 0.0.0.0/0 to 0.0.0.0/0 \ > > peer 192.168.22.110 \ > > srcid <fqdn-of-a> \ > > dstid <fqdn-of-b> > > > > $ cat /etc/pf.conf > > match out on enc0 all nat-to 10.0.5.2 > > > > Machine B (192.168.22.110) > > $ cat /etc/iked.conf > > ikev2 'responder' passive esp \ > > from 0.0.0.0/0 to 10.0.5.0/24 \ > > local egress \ > > peer any \ > > srcid <fqdn-of-b> \ > > tag "ROADW" > > > > $ cat /etc/pf.conf > > pass in on egress proto udp from any to 192.168.22.110 port {500, > > 4500} tag IKED pass in on egress proto esp from any to > > 192.168.22.110 tag IKED pass on enc0 tagged ROADW > > match out on egress inet tagged ROADW nat-to egress > > > > This time there are no double packets to be seen on the interface. > > There are still no responses coming back from packets sent over the > > tunnel > > > > Machine B: > > tcpdump -envps 1500 -i enc0 > > tcpdump: listening on enc0, link-type ENC 13:53:28.672605 > > (authentic,confidential): SPI 0xed1617dd: 192.168.22.222 > 192.16 > > 8.22.110: 10.0.5.2.65031 > <public-dns-ip>.53: [udp sum ok] 53436% > > [1au] A? pool.ntp.org.(41) (ttl 64, id 10351, len 69) (ttl 64, id > > 24158, len 89) 13:53:31.692533 > > (authentic,confidential): SPI 0xed1617dd: 192.168.22.222 > 192.16 > > 8.22.110: 10.0.5.2.65530 > <public-ip>.53: [udp sum ok] 25098% > > [1au] A? pool.nt p.org.(41) (ttl 64, id 37930, len 69) (ttl 64, id > > 48586, len 89) > > put tcpdumps on all the physical interfaces to see where packets > "exit" and not just on the enc0, and look at them there, > also it's not very clear what the test was here, only that a packet > related to resolving stuff (given the <public-dns-ip>.53) > and 10.0.5.2 doing something, which sort-of not matches "machine A > wants all its traffic to go via Machine B" but rather some other > purpose. Since 10.0.5.2 isn't Machine A or B, it gets a bit mixed up > here, does it not? > So, same config as before (-> exact same as in the faq roadwarrior to responder szenario) Command on roadwarrior issued: nc -nvv <public-ip> 22 tcpdump on enc0 of roadwarrior: $ tcpdump -envps 1500 -i enc0 | grep <public-ip> tcpdump: listening on enc0, link-type ENC 14:50:10.306636 (authentic,confidential): SPI 0x76535e5a: 192.168.22.222 > 192.168.22.110: 10.0.5.2.59486 > <public-ip>.22: S [tcp sum ok] 1404707663:1404707663(0) win 16384 <mss 1452,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 1269250476 0> (DF) (ttl 64, id 43924, len 64) (DF) (ttl 64, id 42206, len 84, bad ip cksum 0! -> f2b) tcpdump on enc0 of responder: $ tcpdump -envps 1500 -i enc0 | grep <public-ip> tcpdump: listening on enc0, link-type ENC 14:49:18.271228 (authentic,confidential): SPI 0x76535e5a: 192.168.22.222 > 192.168.22.110: 10.0.5.2.64558 > <public-ip>.22: S [tcp sum ok] 3663687135:3663687135(0) win 16384 <mss 1452,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 222997428 0> (DF) (ttl 64, id 28669, len 64) (DF) (ttl 64, id 44672, len 84) tcpdump on em0 (egress) of responder: tcpdump -envps 1500 -i em0 | grep 94.16.120.200 tcpdump: listening on em0, link-type EN10MB 14:49:18.271272 00:0c:29:b7:74:5f e8:df:70:91:4e:6a 0800 78: 10.0.5.2.64558 > <public-ip>.22: S [tcp sum ok] 3663687135:3663687135(0) win 16384 <mss 1452,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 222997428 0> (DF) (ttl 63, id 28669, len 64) The lo traffic on the roadwarrior is bypassed using ipsec.conf And the 10.0.5.2 is there on purposed as mentioned and described in the FAQ: https://www.openbsd.org/faq/faq17.html#clientopenbsd And yes the public ip I am trying to reach is up and available and trying to connect to it with iked off works as expected. g Stephan
