Re: svn commit: r277714 - head/sbin/ipfw

2015-01-26 Thread Olivier Cochard-Labbé
On Mon, Jan 26, 2015 at 10:50 PM, Nick Hibma  wrote:

>
> > On 26 Jan 2015, at 22:24, John Baldwin  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
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r277714 - head/sbin/ipfw

2015-01-26 Thread Nick Hibma

> On 26 Jan 2015, at 22:24, John Baldwin  wrote:
> 
> On Monday, January 26, 2015 09:34:39 PM Olivier Cochard-Labbé wrote:
>> On Sun, Jan 25, 2015 at 9:37 PM, John Baldwin  wrote:
>>> Author: jhb
>>> Date: Sun Jan 25 20:37:32 2015
>>> New Revision: 277714
>>> URL: https://svnweb.freebsd.org/changeset/base/277714
>>> 
>>> Log:
>>>  natd(8) will work with an unconfigured interface and effectively not do
>>>  anything until the interface is assigned an address.  This fixes
>>>  ipfw_nat to do the same by using an IP of INADDR_ANY instead of
>>>  aborting the nat setup if the requested interface is not yet configured.
>> 
>> Hi,
>> 
>> I've still a problem with ipfw_nat and unconfigured interface:
>> On my setup I'm using ipfw with NAT rules using an OpenVPN tunnel interface
>> as source address for NATting.
>> 
>> During the machine startup, ipfw is started before openvpn (hopefully) and
>> its configuration mention do to NAT using tun0 IP address.
>> Then OpenVPN start and create a tun0 and set an IP address on it.
>> => But no unicast traffic is allowed on this tun0 interface until I restart
>> ipfw.
>> 
>> If I correctly understand the log of this commit: This behavior should be
>> fixed by this commit, right ?
> 
> 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).

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.

Nick
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r277714 - head/sbin/ipfw

2015-01-26 Thread John Baldwin
On Monday, January 26, 2015 09:34:39 PM Olivier Cochard-Labbé wrote:
> On Sun, Jan 25, 2015 at 9:37 PM, John Baldwin  wrote:
> > Author: jhb
> > Date: Sun Jan 25 20:37:32 2015
> > New Revision: 277714
> > URL: https://svnweb.freebsd.org/changeset/base/277714
> > 
> > Log:
> >   natd(8) will work with an unconfigured interface and effectively not do
> >   anything until the interface is assigned an address.  This fixes
> >   ipfw_nat to do the same by using an IP of INADDR_ANY instead of
> >   aborting the nat setup if the requested interface is not yet configured.
> 
> Hi,
> 
> I've still a problem with ipfw_nat and unconfigured interface:
> On my setup I'm using ipfw with NAT rules using an OpenVPN tunnel interface
> as source address for NATting.
> 
> During the machine startup, ipfw is started before openvpn (hopefully) and
> its configuration mention do to NAT using tun0 IP address.
> Then OpenVPN start and create a tun0 and set an IP address on it.
> => But no unicast traffic is allowed on this tun0 interface until I restart
> ipfw.
> 
> If I correctly understand the log of this commit: This behavior should be
> fixed by this commit, right ?

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).

-- 
John Baldwin
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


Re: svn commit: r277714 - head/sbin/ipfw

2015-01-26 Thread Alexander V . Chernikov
   �

   �

   26.01.2015, 23:35, "Olivier Cochard-Labbé" :

   On Sun, Jan 25, 2015 at 9:37 PM, John Baldwin <[1]j...@freebsd.org>
   wrote:

 Author: jhb
 Date: Sun Jan 25 20:37:32 2015
 New Revision: 277714
 URL: [2]https://svnweb.freebsd.org/changeset/base/277714
 Log:
 �  natd(8) will work with an unconfigured interface and effectively
 not do
 �  anything until the interface is assigned an address.�  This fixes
 �  ipfw_nat to do the same by using an IP of INADDR_ANY instead of
 �  aborting the nat setup if the requested interface is not yet
 configured.
 �

   Hi,
   I've still a problem with ipfw_nat and unconfigured interface:
   On my setup I'm using ipfw with NAT rules using an OpenVPN tunnel
   interface as source address for NATting.
   During the machine startup, ipfw is started before openvpn (hopefully)
   and its configuration mention do to NAT using tun0 IP address.
   Then OpenVPN start and create a tun0 and set an IP address on it.
   => But no unicast traffic is allowed on this tun0 interface until I
   restart ipfw.
   If I correctly understand the log of this commit: This behavior should
   be fixed by this commit, right ?

   As far as I understand, nat instance is created with an unresolved ip
   (0.0.0.0 propagated to libalias) and "tun0" interface name. After
   "tun0" creation and address assignment, kernel ipfw_nat ifaddr hook
   should take action and update libalias address to primary? IPv4
   interface address.

   �

References

   1. mailto:j...@freebsd.org
   2. https://svnweb.freebsd.org/changeset/base/277714
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r277714 - head/sbin/ipfw

2015-01-26 Thread Olivier Cochard-Labbé
On Sun, Jan 25, 2015 at 9:37 PM, John Baldwin  wrote:

> Author: jhb
> Date: Sun Jan 25 20:37:32 2015
> New Revision: 277714
> URL: https://svnweb.freebsd.org/changeset/base/277714
>
> Log:
>   natd(8) will work with an unconfigured interface and effectively not do
>   anything until the interface is assigned an address.  This fixes
>   ipfw_nat to do the same by using an IP of INADDR_ANY instead of
>   aborting the nat setup if the requested interface is not yet configured.
>
>

Hi,

I've still a problem with ipfw_nat and unconfigured interface:
On my setup I'm using ipfw with NAT rules using an OpenVPN tunnel interface
as source address for NATting.

During the machine startup, ipfw is started before openvpn (hopefully) and
its configuration mention do to NAT using tun0 IP address.
Then OpenVPN start and create a tun0 and set an IP address on it.
=> But no unicast traffic is allowed on this tun0 interface until I restart
ipfw.

If I correctly understand the log of this commit: This behavior should be
fixed by this commit, right ?
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"


svn commit: r277714 - head/sbin/ipfw

2015-01-25 Thread John Baldwin
Author: jhb
Date: Sun Jan 25 20:37:32 2015
New Revision: 277714
URL: https://svnweb.freebsd.org/changeset/base/277714

Log:
  natd(8) will work with an unconfigured interface and effectively not do
  anything until the interface is assigned an address.  This fixes
  ipfw_nat to do the same by using an IP of INADDR_ANY instead of
  aborting the nat setup if the requested interface is not yet configured.
  
  Differential Revision:https://reviews.freebsd.org/D1539
  Reviewed by:  melifaro, glebius, gnn
  MFC after:1 week

Modified:
  head/sbin/ipfw/nat.c

Modified: head/sbin/ipfw/nat.c
==
--- head/sbin/ipfw/nat.cSun Jan 25 20:16:45 2015(r277713)
+++ head/sbin/ipfw/nat.cSun Jan 25 20:37:32 2015(r277714)
@@ -163,9 +163,9 @@ set_addr_dynamic(const char *ifn, struct
}
}
if (sin == NULL)
-   errx(1, "%s: cannot get interface address", ifn);
-
-   n->ip = sin->sin_addr;
+   n->ip.s_addr = htonl(INADDR_ANY);
+   else
+   n->ip = sin->sin_addr;
strncpy(n->if_name, ifn, IF_NAMESIZE);
 
free(buf);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"