svn commit: r277714 - head/sbin/ipfw

[Olivier Cochard-Labbé]

On Mon, Jan 26, 2015 at 10:50 PM, Nick Hibma <nick at van-laarhoven.org> wrote:

>
> > On 26 Jan 2015, at 22:24, John Baldwin <jhb at freebsd.org> wrote:
> >
> >
> > It might.  What happened for me is that I was using nat over wlan0 for
> VM's
> > on my laptop to reach the outside world, but wlan0 doesn't get an IP
> until
> > later in the boot after it associates.  As a result, wlan0 wasn't
> passing any
> > IP traffic until this fix (or if I reloaded ipfw after wlan0 was
> configured).
>

With a FreeBSD 11-current 277728 I still have the ipfw_nat problem on
unconfigured/unexistant interface.

>
> I don't think it does. The interface is not available until openvpn is
> started.You need to clone the interface during boot by adding
>
>         cloned_interfaces='tun0'
>
> in your /etc/rc.conf. Initialisation is then done later by openvpn.
>
> Let me know if that works for you.
>
>
I've tried with cloned_interfaces too: but same problem.

Here is the status of ipfw just after a boot (ipfw loaded before tun0 IP
setup):

[]~> ipfw show
00100   0     0 allow ip from any to any via lo0
00200   0     0 allow ip from any to any via lo1
00300   0     0 allow ip from any to any via vtnet6
00400   0     0 allow ip from any to any via wlan0
00500 172 21355 nat 1 ip from any to any in via vtnet4
00600  62  4264 nat 2 ip from any to any in via tun0
00700   0     0 check-state
00800   0     0 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67
out via vtnet4
00900   0     0 allow udp from any 67 to me dst-port 68 in via vtnet4
01000   0     0 allow udp from any 67 to 255.255.255.255 dst-port 68 in via
vtnet4
01100   0     0 allow icmp from me to any out via vtnet4 keep-state
01200  11   756 allow udp from me to any dst-port 53 out via vtnet4
keep-state
01300   4   304 allow udp from me to any dst-port 123 out via vtnet4
keep-state
01400 172 21725 allow udp from me to any dst-port 1195 out via vtnet4
keep-state
01500   0     0 nat 1 ip from 10.6.1.0/24,10.6.2.0/24 to any out via vtnet4
01600   0     0 nat 2 udp from me to 2.2.2.2 dst-port 1812,1813 out via tun0
01700  68  4452 allow ip from any to any via tun0
65535   0     0 deny ip from any to any

=> All rules are present (even the "nat 2" table) and seems ok.
=> No packet seems to be denied
But my OSPF adjacency didn't came up on the tun0 interface:

[]~> tcpdump -pni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes
capability mode sandbox enabled
21:25:09.555746 IP 10.0.3.2 > 224.0.0.5: OSPFv2, Hello, length 44
21:25:10.595286 IP 10.0.3.1 > 224.0.0.5: OSPFv2, Hello, length 48
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

=> tcpdump shows only some multicast traffic: It's the problem because ifpw
is filtering all unicast traffic on tun0 in its current state.
For solving this problem I just had to reload ipfw:

[]~> service ipfw restart
net.inet.ip.fw.enable: 1 -> 0
net.inet6.ip6.fw.enable: 1 -> 0
Firewall rules loaded.

=> This fix the problem, unicast traffic are now allowed:

[]~> tcpdump -pni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes
capability mode sandbox enabled
21:25:34.772225 IP 10.0.3.2 > 10.0.3.1: OSPFv2, Database Description,
length 32
21:25:35.784449 IP 10.0.3.1 > 10.0.3.2: OSPFv2, Database Description,
length 32
21:25:35.784550 IP 10.0.3.2 > 10.0.3.1: OSPFv2, Database Description,
length 52
21:25:35.785904 IP 10.0.3.1 > 10.0.3.2: OSPFv2, Database Description,
length 192
21:25:35.786007 IP 10.0.3.2 > 10.0.3.1: OSPFv2, Database Description,
length 32