Date: Fri, 14 Jul 2017 13:42:41 +0200 From: "O. Hartmann" <o.hartmann@walstatt.org> To: FreeBSD CURRENT <freebsd-current@freebsd.org> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, "O. Hartmann" <ohartmann@walstatt.org>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Inter-VLAN routing on CURRENT: any known issues? Message-ID: <20170713211004.13492aef@thor.intern.walstatt.dynvpn.de> In-Reply-To: <c9679df1-e809-3d2b-9432-88664aae3b0a@yandex.ru> References: <20170712214334.4fc97335@thor.intern.walstatt.dynvpn.de> <c9679df1-e809-3d2b-9432-88664aae3b0a@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Thu, 13 Jul 2017 16:12:06 +0300 "Andrey V. Elsukov" <bu7cher@yandex.ru> schrieb: > On 12.07.2017 22:43, O. Hartmann wrote: > > Now the FUN PART: > >=20 > > From any host in any VLAN I'm able to ping hosts on the wild internet v= ia > > their IP, on VLAN 1000 there is a DNS running, so I'm also able to reso= lv > > names like google.com or FreeBSD.org. But I can NOT(!) access any host = via > > http/www or ssh. =20 >=20 > You have not specified where is the NAT configured and its settings is > matters. I use in-kernel NAT. IPFW is performing NAT. In firewall type "OPEN" from t= he vanilla rc.conf, IPFW has instance "nat 123" which provides then NAT. >=20 > VLANs work on the layer2, they do not used for IP routing. Each received > packet loses its layer2 header before it gets taken by IP stack. If an > IP packet should be routed, the IP stack determines outgoing interface > and new ethernet header with VLAN header from this interface is prepended. Since all VLANs are on the same NIC on that router, they should only differ= in the VLAN tag. >=20 > What I would do in your place: > 1. Check the correctness of the switch settings. > - on the router use tcpdump on each vlan interface and > also directly on igb1. Use -e argument to see ethernet header. > Try ping router's IP address from each vlan, you should see tagged > packet on igb1 and untagged on corresponding vlan interface. >=20 > 2. Check the correctness of the routing settings for each used node. > - to be able establish connection from one vlan to another, both nodes > must have a route to each other. >=20 > 3. Check the NAT settings. > - to be able to connect to the Internet from your addresses, you must > use NAT. If you don't have NAT, but it somehow works, this means > that some device does the translation for you, but it's > configuration does not meet to your requirements. And probably you > need to translate prefixes configured for your vlans independently. >=20 According to 1): I consider the settings of the switch now as correct. I have no access to t= he 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 ICMP travel from the router the right way to its destination and back. =46rom any host on any VLAN that is "trunked" through the router, I can ping = any other host on any other VLAN, preferrably not on the same VLAN. By cutting = off the trunk line to the router, pinging stops immediately. =46rom any host on any VLAN I can ping any host which is NATed on the outside world. =46rom the router itself, I can ssh into any host on any VLAN providing ssh service. That said, according to question 3), NAT is considered to be setup correctly. 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 VLAN. According to question 2), the ability to ping from, say, a host on VLAN 100= 0 to another host on VLAN 2 passing through the router would indicate that both sides know their routes to each other. Or am I wrong? I got words from Sean bruno that there might be a problem with the Intel i2= 10 chipset in recent CURRENT - and the hardware on the PCEngine APU 2C4 is thr= ee i210. I'm aware of the problem since r320134 (the oldest CURRENT I started experimenting with the VLAN trunking). I hope it might be a problem with the driver, otherwise I have fully misunderstood FreeBSD's network abilities and techniques :-( I'll provide tcpdump data later. Kind regards, Oliver=20 --=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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170713211004.13492aef>