Date: Fri, 14 Jul 2017 18:32:48 +0200 From: "O. Hartmann" <ohartmann@walstatt.org> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>, "O. Hartmann" <ohartmann@walstatt.org>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Inter-VLAN routing on CURRENT: any known issues? Message-ID: <20170714182055.3cb1768a@thor.intern.walstatt.dynvpn.de> In-Reply-To: <ca7a9e76-9ca3-33f9-c1ef-4c0afd0761ff@yandex.ru> References: <20170712214334.4fc97335@thor.intern.walstatt.dynvpn.de> <c9679df1-e809-3d2b-9432-88664aae3b0a@yandex.ru> <20170713211004.13492aef@thor.intern.walstatt.dynvpn.de> <ca7a9e76-9ca3-33f9-c1ef-4c0afd0761ff@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--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" <bu7cher@yandex.ru> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3D6525bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VL=
AN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IP=
V6>
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170714182055.3cb1768a>