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?
--
May the most significant bit of your life be positive.
