anyone tried the Multi routing table code yet?
Julian Elischer
julian at elischer.org
Fri May 30 09:56:44 UTC 2008
Julian Elischer wrote:
> Rajkumar S wrote:
>> On Sat, May 24, 2008 at 6:09 AM, Julian Elischer <julian at elischer.org>
>> wrote:
>>> subject says it all really..
>>
>> I am using pf and rtable to setfib and get an pfctl: DIOCADDRULE:
>> Device busy when trying to load "pass in quick on fxp0 from any to any
>> keep state rtable 1"
>>
>
> I'm not really familiar with the pf syntax
> as I didn't do that part of the patch (max laier (CC'd) did)
> and I don't use pf.
>
> Max may be able to see if the patch to the pf code ahs an error.
>
>
>
>> I can successfully load "pass in quick on fxp0 all flags S/SA keep
>> state rtable 0" I am testing on FreeBSD CURRENT.
>>
>> My routing tables are:
>>
>>
>> [root at daemon /etc]# setfib -0 netstat -nrf inet
>> Routing tables
>>
>> Internet:
>> Destination Gateway Flags Refs Use Netif
>> Expire
>> default 192.168.3.100 UGS 0 2025 fxp0
>> 127.0.0.1 127.0.0.1 UH 0 0 lo0
>> 192.168.3.0/24 link#1 UC 0 0 fxp0
>> 192.168.3.54 00:40:f4:b7:d7:ee UHLW 1 40 fxp0
>> 1179
>> 192.168.3.100 00:80:48:38:1a:df UHLW 2 149 fxp0
>> 1173
>> 192.168.4.0/24 link#1 UC 0 0 fxp0
>> 192.168.4.4 00:80:48:1f:48:26 UHLW 1 141 fxp0
>> 1120
>> 192.168.5.0/24 link#3 UC 0 0 rue0
>> [root at daemon /etc]# setfib -1 netstat -nrf inet
>> Routing tables
>>
>> Internet:
>> Destination Gateway Flags Refs Use Netif
>> Expire
>> default 192.168.5.4 UGS 0 13 rue0
>> 127.0.0.1 127.0.0.1 UH 0 0 lo0
>> 192.168.3.0/24 link#1 UC 0 0 fxp0
>> 192.168.3.54 00:40:f4:b7:d7:ee UHLW 1 0 fxp0
>> 1176
>> 192.168.3.100 00:80:48:38:1a:df UHLW 1 5 fxp0
>> 1170
>> 192.168.4.0/24 link#1 UC 0 0 fxp0
>> 192.168.4.4 00:80:48:1f:48:26 UHLW 1 0 fxp0
>> 1117
>> 192.168.5.0/24 link#3 UC 0 0 rue0
>>
>> btw, does the rtable syntax allow to set route for packets generated
>> by the pf host itself (like packets from squid). The catch is that
>> they cannot be matched via a "pass in" rule, they are matched only on
>> a "pass out" rule.
>
> I don't know about pf, but in ipfw it definitely can be any packet at
> any time, but the outgoing packets have already made their routing
> decision before they hit the firewall so even though a table is
> associated with the packet, it's too late :-/ it has to be associated
> with the socket itself to really have effect.
For this reason I'm considering whether to add a 'reroute' ipfw rule
that forces a redo of the routing decision... it may not work as
expected however.. (it would be too late to change the selected src
address).
>
>>
>> Thanks and regards,
>>
>> raj
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-net
mailing list