pfSense

Source routing rule is fine during the first time round. And appears in the pfctl output as:

pass in quick on vr0 route-to { (vr1 XX.XX.192.1), (vr1 XX.XX.192.1), (vr1 XX.XX.192.1), (vr1 XX.XX.192.1), (vr1 XX.XX.192.1), (pppoe0 XX.YY.5.203), (pppoe0 XX.YY.5.203) } round-robin sticky-address inet from any to ! <vpndests> flags S/SA keep state label "USER_RULE - Loadbalancing rule for outbound" 

However on subsequent changes of the ruleset we get the error

/tmp/rules.debug:153: sticky-address cannot be redefined

The values at that point in rules.debug are:

GWSOUT = "  route-to { ( vr1 XX.XX.192.1 )  ( vr1 XX.XX.192.1 ), ( vr1 XX.XX.192.1 )  ( vr1 XX.XX.192.1 )  ( vr1 XX.XX.192.1 ) ( pppoe0 XX.XX.5.203 )  ( pppoe0 XX.XX.5.203 )  }  round-robin  sticky-address  " 
...
pass  in  quick  on $LAN  $GWSOUT  from any to  ! $vpndests keep state  label "USER_RULE: Loadbalancing rule for outbound" 

And a diff with the older rules.debug.old does not yield any change which obviously can cause this. And it is still the first LAN rule defined in the rules file.

However commenting out the first of the two rules furter up:

pass  in  quick  on $WAN11 reply-to ( vr1 XX.XX.192.1 )  inet proto icmp  from any to XX.XX.207.185 icmp-type echoreq keep state  label "USER_RULE: Allow ICMP as matter of courtesy" 
pass  in  quick  on $WAN2 reply-to ( pppoe0 XX.XX.5.203 )  inet proto icmp  from any to XX.XX.239.115 icmp-type echoreq keep state  label "USER_RULE: Allow ICMP as matter of courtesy" 

does allow the rule file to parse. Wether or not the second entry (WAN2) is commented out does not seem to matter. WAN1 and WAN2 are identical but for their order and the fact that WAN1 is a simple fiber/dumb-modem while the other is a ADSL PPPoE.

Simplifying that first rule to just

pass  in  quick  on $WAN1 inet proto icmp  from any to XX.XX.207.185 icmp-type echoreq keep state  label "USER_RULE: Allow ICMP as matter of courtesy" 

or even

pass  in  quick  on $WAN1 inet proto icmp  from any to any icmp-type echoreq keep state 

does not help. Not sure if this is a pfsense rule generation (ordering) bug or something in pf itself.