From owner-freebsd-current@freebsd.org Fri Jul 14 16:32:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B28ADDA6CEF; Fri, 14 Jul 2017 16:32:58 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E94C6BE48; Fri, 14 Jul 2017 16:32:57 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.149.38]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lux3h-1detKC2JNJ-0103GT; Fri, 14 Jul 2017 18:32:49 +0200 Date: Fri, 14 Jul 2017 18:32:48 +0200 From: "O. Hartmann" To: "Andrey V. Elsukov" Cc: FreeBSD CURRENT , "O. Hartmann" , FreeBSD Questions Subject: Re: Inter-VLAN routing on CURRENT: any known issues? Message-ID: <20170714182055.3cb1768a@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20170712214334.4fc97335@thor.intern.walstatt.dynvpn.de> <20170713211004.13492aef@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/3=t_J+X+OLY8=raZazOl390"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:AaoerBJpBE5VPTrXV7GVepINPT3JlvWXtIVtVCV01d5sdF1dMTL Z0zZpvrrl2Y+OaDH8bz3xbG5DSd2i1p0rONmMqGXdbUwstanWIkODGNuzvMibhAy2eAU7NY 4jL8e+kji+VqnMgvn2bUfGFVxf9eIFZgxLilLV3rfkpane16n+Gr8yVSPRTmO6PX+zF8++S mLq2oLZjQ/ev06CdR/B+w== X-UI-Out-Filterresults: notjunk:1;V01:K0:8fiUIRnHfVU=:U/xeMCQqVWwAZa9toSEUjK jySiNO3jUbLXgZwUngPejK4ghdujvR6jqnxJ5y8U5cc4LOCvFh122yfPPK5ILrElMEy96WgAx Gyf/kMr31i2lirwPPNTYv1z/wz9c2aQSAccWdYD9TeJTvM3nrRoDAv8c5d03uVxZCowpGB1r5 ++FshfF+MC4tJbLKIOwgSTtBO87sHffF0UilF6IaP2PB7vuHnTzVCamN1o+3x7pvYCZK5WZzI h5rrH9+hANh0xHX8iN/wOBlmUscz2cILigzySf8SXykuN7Ua6F+Toek6FEynfb7bXhwG6dZcQ LPbqQxMopuRi/CseWeIkG7zKQ9iuayCkChJqGCIteVBxHKcG4qgtLkZWloAOPjZ3iV/Sbx+fx cVucDV8gaOYFGkjhka/jVJ/J52Usu5/U6ab9elVCdyOBWuRAyi+C6yRti5buVv2fXxkv/c0T5 KTnZ3+xEAgYaVACS8MDsDl5pkpGNY/Y/q29fN08sOO+wrbo0Pci/wClGJ6GnyO14pV7PwLw0i ZtUrp5U/xqFdGRjAkA6duMO2EsFz0aglmFLu+ddtEitDX4pcHfwIEnLIRJAjKSqncHAVyL5Ia T5IQpmZ/9GaEhnvCBXxv0vGxCNmxzxVemfk2uD16pf93G6nMyemIS3Hlcpbuc3VRKz9i4eld5 HT5k7K5Z3kP1PXWpOYFoNByPyzVZuMkP+Muw1WF8JN0SpfgaWZrBqDM6pZ0XBS6imKODQNzbb iWM6SEmL4trvhkSKJaoHWx6x4ko/bYbAw+s7e0j0zjLdpVZrmbz6gvuwkBCwW/1JPNctyoEbN Mx4QvJT3BtwxmGLyi9t71RvEOd9ZQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 16:32:58 -0000 --Sig_/3=t_J+X+OLY8=raZazOl390 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Fri, 14 Jul 2017 15:00:30 +0300 "Andrey V. Elsukov" schrieb: > On 14.07.2017 14:42, O. Hartmann wrote: > > I use in-kernel NAT. IPFW is performing NAT. In firewall type "OPEN" fr= om the > > vanilla rc.conf, IPFW has instance "nat 123" which provides then NAT. = =20 >=20 > I never used default config types for firewall, so, it would be nice to > see what rules do you have. Me neither except on some hosts with very little complications in their set= ups or simple clients. >=20 > # ipfw show The OPEN firewall rules, which show the very same behaviour as I stated bef= ore: root@gate:~ # ipfw list 00050 nat 123 ip4 from any to any via tun0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 deny ip from any to any > # ipfw nat show config root@gate:~ # ipfw nat show config ipfw nat 123 config if tun0 log or ipfw nat 1 config if tun0 log same_ports reset redirect_port tcp 192.168.0.= 111:9734 9734 redirect_port tcp 192.168.0.111:5432 5432 redirect_port udp 192.168.2.1:242= 7 2427 redirect_port udp 192.168.2.1:4569 4569 redirect_port udp 192.168.2.1:5060 = 5060 redirect_port tcp 192.168.2.1:5060 5060 redirect_port tcp 192.168.0.111:443= 443 redirect_port tcp 192.168.0.111:80 80 redirect_port tcp 192.168.0.111:22 22 >=20 > >> VLANs work on the layer2 =20 > > According to 1): > >=20 > > I consider the settings of the switch now as correct. I have no access = to the > > router right now. But I did short experiments yesterday evening and it = is > > weird: loged in on thr router, I can ping every host on any VLAN, so IC= MP > > travel from the router the right way to its destination and back. > >=20 > > From any host on any VLAN that is "trunked" through the router, I can p= ing any > > other host on any other VLAN, preferrably not on the same VLAN. By cutt= ing off > > the trunk line to the router, pinging stops immediately. > >=20 > > From any host on any VLAN I can ping any host which is NATed on the out= side > > world. > >=20 > > From the router itself, I can ssh into any host on any VLAN providing s= sh > > service. That said, according to question 3), NAT is considered to be s= etup > > correctly. > >=20 > > Now the strange things: Neither UDP, nor TCP services "flow" from hosts= on one > > VLAN to hosts on a different VLAN. Even ssh doens't work.=20 > > When loged in onto the router, I can't "traceroute" any host on any VLA= N. =20 >=20 > This is most likely due to the problem with firewall rules. > If you set net.inet.ip.firewall.enable=3D0, does it solve the problem with > TCP/UDP between hosts on a different VLANs? net.inet.ip.firewall.enable does not exist, I suppose it is net.inet.ip.fw.= enable. Not, it doesn't change anything, last rule in my list is deny all, as you c= an see above (in-kernel). >=20 > > According to question 2), the ability to ping from, say, a host on VLAN= 1000 to > > another host on VLAN 2 passing through the router would indicate that b= oth > > sides know their routes to each other. Or am I wrong? =20 >=20 > Yes. >=20 > > I got words from Sean bruno that there might be a problem with the Inte= l i210 > > chipset in recent CURRENT - and the hardware on the PCEngine APU 2C4 is= three > > i210. I'm aware of the problem since r320134 (the oldest CURRENT I star= ted > > experimenting with the VLAN trunking). =20 >=20 > It is very strange problems, why ICMP works, but TCP/UDP does not? :) > You can try to disable any type of offloading for the card, there were > some problems in the past with checksum offlading, that may lead to the > problems with TCP, but this usually should be noticeable in the tcpdump > output. >=20 I tried that, but somehow I do not have any check: ifconfig_igb1=3D"up" #ifconfig_igb1=3D"inet6 ::1 prefixlen 64 mtu 6121" create_args_igb1=3D"-tso -lro -rxcsum -txcsum -rxcsum6 -txcsum6 -vlanhwtso = -vlanhwcsum -vlanhwfilter -vlanhwtag" and ifconfig igb1: igb1: flags=3D8843 metric 0 mtu 1500 options=3D6525bb Kind regards, Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/3=t_J+X+OLY8=raZazOl390 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWWjyMAAKCRDS528fyFhY lG8wAf4rs8/mrXg5Xrh1nXcf81faUVZwpFe/W4c8AlMevv7ESJ9DyJnEU93gIVNM 92pShy09yMT/n9QwGFa+uyli3GXuAfwLTVjWDGxKuRyH0988UCdVZ1Z+RnzJ2xOI axcHT+k51gMLxQHRQ8GJu+gl7Ve4WbadfxV4FDFBpobPsxwk4Cmj =3HSF -----END PGP SIGNATURE----- --Sig_/3=t_J+X+OLY8=raZazOl390--