I set up a rule to respond to diagnostic pings from a ISP's router, but it does not seem to follow the reply-to directive. Given the limited state information for ICMP and the state requirements for reply-to, I wonder if I can expect the reply-to part of this rule to work:
65: pass in log on $ext_if2 reply-to ($ext_if2 $ext_gw2) inet proto icmp all icmp-type echoreq keep state >From pfctl -vv -s rules, I see that the state is created: fxp1 icmp x.y.101.245:23605 <- x.y.100.44:23605 0:0 age 00:00:08, expires in 00:00:02, 1:1 pkts, 128:128 bytes, rule 65 id: 42711815000e7e2d creatorid: 75cf03fe Note: fxp0 <=> ext_if1, fxp1 <=> ext_if2 But the response is going out ext_if1 when I expect ext_if2 due to reply-to. It only gets caught in the last rule which redirects packets sourced from an address associated with the alternate interface: 115: pass out log on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any keep state With logging enabled, the transaction looks like this: tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0 rule 65/0(match): pass in on fxp1: x.y.100.44 > x.y.101.245: icmp: echo request (id:5c35 seq:16439) (DF) (ttl 62, id 0) rule 115/0(match): pass out on fxp0: x.y.101.245 > x.y.100.44: icmp: echo reply (id:5c35 seq:16439) (DF) (ttl 255, id 11214)
