Re: svn commit: r277714 - head/sbin/ipfw
� � 26.01.2015, 23:35, Olivier Cochard-Labbé oliv...@cochard.me: 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
On Monday, January 26, 2015 09:34:39 PM Olivier Cochard-Labbé wrote: On Sun, Jan 25, 2015 at 9:37 PM, John Baldwin j...@freebsd.org 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
On 26 Jan 2015, at 22:24, John Baldwin j...@freebsd.org 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 j...@freebsd.org 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
On Mon, Jan 26, 2015 at 10:50 PM, Nick Hibma n...@van-laarhoven.org wrote: On 26 Jan 2015, at 22:24, John Baldwin j...@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 ___ 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
On Sun, Jan 25, 2015 at 9:37 PM, John Baldwin j...@freebsd.org 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
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
