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 <[email protected]> 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
