Apologies, correction: obsd3# pfctl -f /etc/pf.conf
Should be: obsd2# pfctl -f /etc/pf.conf Joe On Sat, May 12, 2018 at 9:37 PM Joseph Crivello <josephcrive...@gmail.com> wrote: > I cannot get reply-to working with if-bound under any circumstances. It > works fine with floating, though. > Is this expected behavior? The (similar) route-to option works fine with > if-bound rules, and I cannot find any documentation that states reply-to > cannot be used with if-bound rules. > Assuming that this is NOT expected behavior, then this is a bug in at least > 6.2 through -current. > I set up three virtual machines running -current today, in order to > reproduce this with a basic test case: > obsd1# echo "inet 10.84.31.10 255.255.255.0" > /etc/hostname.vmx1 > obsd1# echo "inet 10.84.32.10 255.255.255.0" > /etc/hostname.vmx2 > obsd1# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf > obsd1# reboot > ... > obsd1# route add -net 10.84.33.0/24 10.84.31.11 > obsd2# echo "inet 10.84.31.11 255.255.255.0" > /etc/hostname.vmx1 > obsd2# echo "inet 10.84.32.11 255.255.255.0" > /etc/hostname.vmx2 > obsd2# echo "inet 10.84.33.11 255.255.255.0" > /etc/hostname.vmx3 > obsd2# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf > obsd2# reboot > ... > obsd2# echo "pass in log on vmx1 inet from 10.84.31.10 to 10.84.33.12 keep > state (if-bound) reply-to 10.84.32.10@vmx2" >> /etc/pf.conf > obsd3# pfctl -f /etc/pf.conf > Host "obsd3" has just one interface, with IP 10.84.33.12. > No other changes were made to the hosts besides selecting typical > installation options. > If we test this setup with an ICMP echo to 10.84.33.12 from obsd1, here is > what we observe: > obsd1# ping -c 1 10.84.33.12 > PING 10.84.33.12 (10.84.33.12): 56 data bytes > ^C > --- 10.84.33.12 ping statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > obsd2# tcpdump -nvvpi vmx1 icmp > tcpdump: listening on vmx1, link-type EN10MB > 21:20:08.710088 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e > seq:0) [icmp cksum ok] (ttl 255, id 23663, len 84) > ^C > 1 packets received by filter > 0 packets dropped by kernel > obsd2# tcpdump -nvvpi vmx2 icmp > tcpdump: listening on vmx2, link-type EN10MB > ^C > 0 packets received by filter > 0 packets dropped by kernel > obsd2# tcpdump -nvvpi vmx3 icmp > tcpdump: listening on vmx3, link-type EN10MB > 21:20:08.710136 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e > seq:0) [icmp cksum ok] (ttl 254, id 23663, len 84) > 21:20:08.710249 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:306e seq:0) > [icmp cksum ok] (ttl 255, id 8694, len 84) > 21:20:08.710272 10.84.33.11 > 10.84.33.12: icmp: 10.84.31.10 protocol 1 > port 40981 unreachable [icmp cksum ok] for 10.84.33.12 > 10.84.31.10: icmp: > echo reply (id:306e seq:0) (ttl 254, id 8694, len 84, bad ip cksum 44f5! -> > 45f5) (ttl 255, id 637, len 56) > ^C > 3 packets received by filter > 0 packets dropped by kernel > If we change the PF rule we created on obsd2 to "floating" and run the same > test again, then the test case works exactly as expected: > obsd1# ping -c 1 10.84.33.12 > PING 10.84.33.12 (10.84.33.12): 56 data bytes > 64 bytes from 10.84.33.12: icmp_seq=0 ttl=254 time=0.528 ms > --- 10.84.33.12 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 0.528/0.528/0.528/0.000 ms > obsd2# tcpdump -nvvpi vmx1 icmp > tcpdump: listening on vmx1, link-type EN10MB > 21:25:24.970742 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec > seq:0) [icmp cksum ok] (ttl 255, id 27013, len 84) > ^C > 1 packets received by filter > 0 packets dropped by kernel > obsd2# tcpdump -nvvpi vmx2 icmp > tcpdump: listening on vmx2, link-type EN10MB > 21:25:24.971146 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec seq:0) > [icmp cksum ok] (ttl 254, id 13581, len 84) > ^C > 3 packets received by filter > 0 packets dropped by kernel > obsd2# tcpdump -nvvpi vmx3 icmp > tcpdump: listening on vmx3, link-type EN10MB > 21:25:24.970800 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec > seq:0) [icmp cksum ok] (ttl 254, id 27013, len 84) > 21:25:24.970933 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec seq:0) > [icmp cksum ok] (ttl 255, id 13581, len 84) > ^C > 2 packets received by filter > 0 packets dropped by kernel > I am interested in any feedback on the question of whether or not this is > expected behavior... > Thank you. > Joe > On Thu, May 10, 2018 at 1:50 AM Joe Crivello <josephcrive...@gmail.com> > wrote: > > Hello! > > I have a trunk0 interface on a router (#1) that is used for a singular > > purpose -- to pass (IPsec protected) traffic for an IPIP tunnel (gif0) to > > another router (#2). I have configured PF rules on router #1 that prevent > > any other type of traffic from passing on trunk0. There are several > routing > > table entries that forward to router #2 on gif0. > > My objective is to configure an additional pass rule that would allow SSH > > traffic destined for router #1 to pass in and out on trunk0. > > The problem is that the aforementioned routes on gif0 cause packets sent > in > > reply to incoming SSH traffic to pass out on gif0 (after passing in on > > trunk0). This ends up getting blocked by PF on router #1 because the > > state-policy is set to if-bound (which is how I want it). I am trying to > > use reply-to to enforce symmetric routing, but it isn't working. > > As you will see below, my "reply-to" rule is matched, but the reply is > > _still_ routed to gif0: > > # tcpdump -nevvpi pflog0 tcp port 22 > > tcpdump: WARNING: snaplen raised from 116 to 224 > > tcpdump: listening on pflog0, link-type PFLOG > > 01:27:46.503040 rule 5/(match) [uid 0, pid 16018] pass in on trunk0: [uid > > 4294967295, pid 100000] [SSH CLIENT IP].57427 > [TRUNK0 IP].22: S [tcp sum > > ok] 1707770457:1707770457(0) win 64240 <mss 1460,nop,wscale > > 8,nop,nop,sackOK> (DF) (ttl 127, id 24244, len 52) > > 01:27:46.503069 rule 4/(match) [uid 0, pid 16018] block out on gif1: [uid > > 4294967295, pid 100000] [TRUNK0 IP].22 > [SSH CLIENT IP].57427: S [tcp sum > > ok] 4100262020:4100262020(0) ack 1707770458 win 16384 <mss > > 1460,nop,nop,sackOK,nop,wscale 3> (DF) (ttl 64, id 43497, len 52, bad ip > > cksum 0! -> d71b) > > ^C > > 2 packets received by filter > > 0 packets dropped by kernel > > # pfctl -sr | grep @5 > > @5 pass in log quick on trunk0 inet proto tcp from any to [TRUNK0 IP] port > > = 22 flags S/SA keep state (if-bound) reply-to <ROUTER #2 IP>@trunk0 > > Router #1 is running OpenBSD 6.2. > > Anyone have any idea why this isn't working the way I want it to? > > Joe
