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
[-- Attachment #1 --]
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" from the
> > vanilla rc.conf, IPFW has instance "nat 123" which provides then NAT.
>
> 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 setups or simple
clients.
>
> # ipfw show
The OPEN firewall rules, which show the very same behaviour as I stated before:
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:2427 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
>
> >> VLANs work on the layer2
> > According to 1):
> >
> > 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 ICMP
> > travel from the router the right way to its destination and back.
> >
> > From 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.
> >
> > From any host on any VLAN I can ping any host which is NATed on the outside
> > world.
> >
> > From 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.
> > When loged in onto the router, I can't "traceroute" any host on any VLAN.
>
> This is most likely due to the problem with firewall rules.
> If you set net.inet.ip.firewall.enable=0, 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 can see above
(in-kernel).
>
> > 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 both
> > sides know their routes to each other. Or am I wrong?
>
> Yes.
>
> > I got words from Sean bruno that there might be a problem with the Intel 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 started
> > experimenting with the VLAN trunking).
>
> 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.
>
I tried that, but somehow I do not have any check:
ifconfig_igb1="up"
#ifconfig_igb1="inet6 ::1 prefixlen 64 mtu 6121"
create_args_igb1="-tso -lro -rxcsum -txcsum -rxcsum6 -txcsum6 -vlanhwtso -vlanhwcsum
-vlanhwfilter -vlanhwtag"
and ifconfig igb1:
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6525bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
Kind regards,
Oliver
--
O. Hartmann
Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWWjyMAAKCRDS528fyFhY
lG8wAf4rs8/mrXg5Xrh1nXcf81faUVZwpFe/W4c8AlMevv7ESJ9DyJnEU93gIVNM
92pShy09yMT/n9QwGFa+uyli3GXuAfwLTVjWDGxKuRyH0988UCdVZ1Z+RnzJ2xOI
axcHT+k51gMLxQHRQ8GJu+gl7Ve4WbadfxV4FDFBpobPsxwk4Cmj
=3HSF
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170714182055.3cb1768a>