Change Details

I've ran the tests from `/usr/tests/sys/netpfil/pf`, all pass. The issue was found when playing with this rule: `` pass in quick on n_test_h_rtr \ route-to { ( n_srv_h_rtr <serversA> ) , ( nonexistent <serversB> ) } round-robin sticky-address \ proto tcp \ to <lb_pool> port 80 \ tag maciora ``` The client has multiple IP addresses it can use as source. It first makes a connection from source1 which lands on serverA2@n_srv_h_rtr (this thing always starts at 2 for whatever reason, that is not important for this bug). Then the next connection is made from source2 and lands on serverA3@n_srv_h_rtr. The next connection is made from source3 and lands on serverB1@nonexistent. This updates `r->rpool.cur` which is now used for all new connections, even ones matching existing source nodes. A new connection from the client from source1 fails because it gets mapped to serverA2@nonexistent, as only the IP address is stored in the source node.

I've ran the tests from `/usr/tests/sys/netpfil/pf`, all pass. The issue was found when playing with this rule: ``` pass in quick on n_test_h_rtr \ route-to { ( n_srv_h_rtr <serversA> ) , ( nonexistent <serversB> ) } round-robin sticky-address \ proto tcp \ to <lb_pool> port 80 \ tag maciora ``` The client has multiple IP addresses it can use as source. It first makes a connection from source1 which lands on serverA2@n_srv_h_rtr (this thing always starts at 2 for whatever reason, that is not important for this bug). Then the next connection is made from source2 and lands on serverA3@n_srv_h_rtr. The next connection is made from source3 and lands on serverB1@nonexistent. This updates `r->rpool.cur` which is now used for all new connections, even ones matching existing source nodes. A new connection from the client from source1 fails because it gets mapped to serverA2@nonexistent, as only the IP address is stored in the source node.

I've ran the tests from `/usr/tests/sys/netpfil/pf`, all pass. The issue was found when playing with this rule: ``` pass in quick on n_test_h_rtr \ route-to { ( n_srv_h_rtr <serversA> ) , ( nonexistent <serversB> ) } round-robin sticky-address \ proto tcp \ to <lb_pool> port 80 \ tag maciora ``` The client has multiple IP addresses it can use as source. It first makes a connection from source1 which lands on serverA2@n_srv_h_rtr (this thing always starts at 2 for whatever reason, that is not important for this bug). Then the next connection is made from source2 and lands on serverA3@n_srv_h_rtr. The next connection is made from source3 and lands on serverB1@nonexistent. This updates `r->rpool.cur` which is now used for all new connections, even ones matching existing source nodes. A new connection from the client from source1 fails because it gets mapped to serverA2@nonexistent, as only the IP address is stored in the source node.