ipfw and netgraph confusion

Christopher Cowart ccowart at rescomp.berkeley.edu
Sat Nov 17 16:32:40 PST 2007


Hello,

I'm trying to use the ng_nat node on 6.2.

I have one set of IP -> ng cookie mappings in tables and a single
default mapping for anything that doesn't match the tables.

The first case, using tables, is the "Authenticated" case:
| /sbin/ipfw add netgraph tablearg all from "table(4)" to any in via \
|   vlan88
| 01040 netgraph tablearg ip from table(4) to any in via vlan88
| /sbin/ipfw add netgraph tablearg all from any to "table(3)" in via \
|   vlan665
| 01060 netgraph tablearg ip from any to table(3) in via vlan665
| /sbin/ipfw table 4 list
| 10.8.62.255/32 200065132
| /sbin/ipfw table 3 list
| 169.229.65.132/32 100065132

This case works great. I inserted some count log rules an see that the
src and dst IP addresses are being altered as I would expect.

When I fall back to the default case for "Unauthenticated" users:
| /sbin/ipfw add netgraph 100079145 all from 10.8.0.0/18 to any in \
|     via vlan88
| 01230 netgraph 5673 ip from 10.8.0.0/18 to any in via vlan88 
| /sbin/ipfw add netgraph 200079145 all from any to 169.229.79.145
| 01240 netgraph 63273 ip from any to 169.229.79.145

Notice the netgraph cookies here are 100079145 and 200079145. These are
the same values I used with ng_ctl. The resulting ipfw rules say the
cookies are 5673 and 63273. After matching the netgraph rules in this
case, the src and dst IP addresses are logged unchanged. This leads me 
to believe ipfw sent them to non-existant nodes. The behavior I'm
witnessing indicates that indeed, these packets have not been NATed.

Troubleshooting a bit, I noticed that if I change the constant numbers
to 10 and 20, things work exactly as expected. I'm going to venture a
guess that when a netgraph cookie is parsed on the commandline, it's
interpreted as a 16-bit int, but when you're using tableargs, 32-bit
ints work. This inconsistent behavior is a bit confusing (and led me to
a couple hours of frustrated debugging). Anyone else aware of this
problem? Should I file a PR?

Thanks,

-- 
Chris Cowart
Lead Systems Administrator
Network & Infrastructure Services, RSSP-IT
UC Berkeley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20071118/2ad8b8d5/attachment.pgp


More information about the freebsd-net mailing list