[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

round-robin nat vs. vpn aliases



  hello.
  rather by stupid error, i ended up moving up to 3.3 ( -current )
  on my main NAT gateway at home.  
  myself and a friend have an isakmpd VPN between us.
  perhaps it was not the only way to do it, but one way we got
  routing to work between the two VPN subnets ( 192.168.7/27, 
  192.168.23.128/24 ) was to create aliases on our external 
  interfaces( fxp0 ) ( eg: ifconfig fxp0 alias 192.168.7.19 ),
  and then add a route such as: '/sbin/route add -net \
  192.168.23.128/25 192.168.7.19'.
  this created an issue for my nat rule:
$e = "fxp0"
nat on $e from 192.168.7.0/27 to any -> $e
  as with the new awareness of fxp0 brought by the round-robin
  thing in pf, fxp0 expanded to both my IP given by ISP *and* 
  192.168.7.19...
  obviously, half the packets leaving from NATted clients were
  from my DHCP'd IP, the other half with a source, as the travelled
  about the net, of 192.168.7.19.  ( = bad in my case ).
  i've been able to successfully move the aliases off of fxp0 onto
  fxp1, and the vpn still functions ( by using '-interface' in the
  /sbin/route ); but i was wondering if this is something that 
  has a chance of creating snags for people, such as myself, who
  might not initially have it occur to them how to fix it, and
  as such, have some provision in pf to disable the 'round-robin'
  thing even if more than one IP exists on the interface that
  the nat is '->'ed to.  
  naturally, i could simply put my currently assigned IP in the
  pf.conf instead of the $e macro( or otherwise come up with the
  work around i alluded to with '-interface', as specifying the
  IP of my external interface is something less than appealing, 
  as it is subject to change potentially every 13 hours ( my 
  lease time )); and again, it's not causing me an issue at the
  moment, but i wanted to throw it out there in case it's something
  you ( david, henning, etc ) would feel valuable to somehow 
  highlight in the pf.conf dox.  ( as in, if you have goofy aliases
  on your external interface and refer to it by interface name in
  your NAT rules, be aware that round-robin *will* use all of them
  in turn ).  
  adding a switch/argument/conf-file dealie to force off round-robin
  might also be a work-around, but if you feel that that is a 
  useless feature ( bloat ), i'd understand completely.
  my thanks for your continued work.
  jared.