Problem forward/postroute http/https thru vlan-ed interface.

[Mimiko]

Hello.

Recently I tried to combine multiple ISP using a layer 2 switch into one
port connected to a debian wheezy router.

I set up in interfaces:
auto eth0
iface eth0 inet static
address local_lan_ip
netmask mask
auto eth1.2
iface eth1.2 inet static
address isp1
netmask mask
auto eth1.4
iface eth2.4 inet static
address isp2
netmask mask

VLAN ID 2 is for tagging to ISP1
VLAN ID 4 is for tagging to ISP2

Also for load balancing I do:
ip route replace default scope global nexthop via $eth1.2_gateway dev
$eth1.2_eth weight 100 nexthop via $eth2.4_gateway dev $eth2.4_eth
weight 100

In iptables I do:

iptables -t nat -A POSTROUTING -o eth1.2 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1.4 -j MASQUERADE

iptables -A FORWARD -j ACCEPT

Now when i ping from the linux router - it works.
When I ping from some workstation behind router - it works.
When I open some ftp from workstation - it works.

But, when I try to open a web page from workstation - it does not work.
I even tried on linux router:
wget google.com
and after resolving to ip it waited long long time to download page and
didn't received any packet.

What is wrong with http/htpps ? Why icmp works, ftp works, but
http/https is not working?

The same configuration of iptables, ip route but moving to eth1 and eth2
- physical interfaces for each ISP - all works as it should be.

Thank you.


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/550DEED8...@gmail.com

[Bob Proulx]

Mimiko wrote:
> I set up in interfaces:
> auto eth0
> iface eth0 inet static
> address local_lan_ip
> netmask mask
> auto eth1.2
> iface eth1.2 inet static
> address isp1
> netmask mask
> auto eth1.4
> iface eth2.4 inet static
> address isp2
> netmask mask
>
> VLAN ID 2 is for tagging to ISP1
> VLAN ID 4 is for tagging to ISP2

I see no vlans in your configuration above. The above simply shows
additional IP addresses being assigned. If your switch is requiring
vlan tagging then that is likely your problem.

See the documentation for setting up vlans here:

https://wiki.debian.org/NetworkConfiguration

Bob

[Sven Hartge]

Bob Proulx <b...@proulx.com> wrote:
> Mimiko wrote:

>> I set up in interfaces:
>> auto eth0
>> iface eth0 inet static
>> address local_lan_ip
>> netmask mask
>> auto eth1.2
>> iface eth1.2 inet static
>> address isp1
>> netmask mask
>> auto eth1.4
>> iface eth2.4 inet static
>> address isp2
>> netmask mask
>>
>> VLAN ID 2 is for tagging to ISP1
>> VLAN ID 4 is for tagging to ISP2

> I see no vlans in your configuration above. The above simply shows
> additional IP addresses being assigned. If your switch is requiring
> vlan tagging then that is likely your problem.

Ah, nope.

It's "magic". Since Wheezy ifupdown knows the notation
"interface dot VLAN-ID" and automatically creates an appropriatly
configured interface. (In Squeeze you needed the "vlan"-package or a
small scriptled in /etc/network/if-pre-up.d to issue the correct
"ip"-commands.)

Try for you self, put one config like the above in your
network/interfaces file and use "ifup -v" to see what commands are used.

Also see the man-page for interfaces(5):

,----
| VLAN AND BRIDGE INTERFACES
| To ease the configuration of VLAN interfaces, interfaces having .
| (full stop character) in the name are configured as 802.1q tagged vir‐
| tual LAN interface. For example, interface eth0.1 is a virtual inter‐
| face having eth0 as physical link, with VLAN ID 1.
`----

> See the documentation for setting up vlans here:

> https://wiki.debian.org/NetworkConfiguration

That is horribly outdated. It even says "Etch" on the part for VLANs.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/hbfnsl...@mids.svenhartge.de

[Bob Proulx]

Sven Hartge wrote:

> Bob Proulx <b...@proulx.com> wrote:
> > I see no vlans in your configuration above. The above simply shows
> > additional IP addresses being assigned. If your switch is requiring
> > vlan tagging then that is likely your problem.
>
> Ah, nope.
>
> It's "magic". Since Wheezy ifupdown knows the notation
> "interface dot VLAN-ID" and automatically creates an appropriatly
> configured interface. (In Squeeze you needed the "vlan"-package or a
> small scriptled in /etc/network/if-pre-up.d to issue the correct
> "ip"-commands.)

What? They have changed the syntax and I am out of date?! Horrors! :-/
I will go and learn the new syntax for these things.

VLAN AND BRIDGE INTERFACES
To ease the configuration of VLAN interfaces, interfaces having .

(full stop character) in the name are configured as 802.1q tagged vir-
tual LAN interface. For example, interface eth0.1 is a virtual inter-

face having eth0 as physical link, with VLAN ID 1.

For compatibility with bridge-utils package, if bridge_ports option is
specified, VLAN interface configuration is not performed.

Thanks for pointing this out.

> > See the documentation for setting up vlans here:
>
> > https://wiki.debian.org/NetworkConfiguration
>
> That is horribly outdated. It even says "Etch" on the part for VLANs.

Would you feel like updating it? It is a wiki after all.

Bob

[Bob Proulx]

Mimiko wrote:
> What is wrong with http/htpps ? Why icmp works, ftp works, but http/https is
> not working?

Since Sven pointed out that I was out of date I no longer have a
clue.

To debug this I would run tcpdump on both sides of the router and
examine the packets for http and verify that they are being passed
through and NAT'd correctly. You should be able to verify the return
packets through the router. If there is a problem along the way then
you should be able to see where the packets are getting lost. That
should point to the problem.

> The same configuration of iptables, ip route but moving to eth1 and eth2 -
> physical interfaces for each ISP - all works as it should be.

IMNHO if you can use two different physical interfaces then I think
that is the better way to do it.

Bob

[Mimiko]

Well.

I did some test today to with tcpdump. It's realy strange. First I
uninstalled vlan. Configured all again. using tcpdump I saw it was
sending packets. But at first it didn't want to work.

I added 8021q to /etc/modules, rebooted server and as I wrote: ping
works, ftp works, but not http.

The strange thing that as soon I am doing `tcpdump -i eth1 -ne`, where
eth1 is the interface to the internet and vlan configured, http starts
working. So in a start up script I've put:

timeout 1 tcpdump -i eth1 -ne

Its strange that this is needed to start web to work.

I think its not wright this. Is this tipical?

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/550F0BE2...@gmail.com

[Sven Hartge]

Mimiko <vbv...@gmail.com> wrote:

> I did some test today to with tcpdump. It's realy strange. First I
> uninstalled vlan. Configured all again. using tcpdump I saw it was
> sending packets. But at first it didn't want to work.

> I added 8021q to /etc/modules, rebooted server and as I wrote: ping
> works, ftp works, but not http.

Which is very very strange. If FTP works, which is a TCP-based protocol
like HTTP, then HTTP should work as well. FTP, with its two connections
(control and data) being a much bigger pain in the ass to a) firewall
and b) masquerade, is normally the procotol which does not work in a
complex setup.

> The strange thing that as soon I am doing `tcpdump -i eth1 -ne`, where
> eth1 is the interface to the internet and vlan configured, http starts
> working. So in a start up script I've put:

> timeout 1 tcpdump -i eth1 -ne

You can use something like "ip link set dev $DEVICE promisc on" so
toggle that, no need to run a tcpdump in the background.

> Its strange that this is needed to start web to work.

> I think its not wright this. Is this tipical?

No, this is not typical.

Something smells fishy here. Forcing a device into promiscuous to get it
working in my book normally indicates a problem with the driver (or the
hardware).

For example I once had a problem with the via-velocity network driver
and IPv6, which only started working once I put the device into
promiscuous mode because the driver did not correctly configure the
hardware for multicasts.

What kind of network card and kernel version do you use?

Please show the unmodified (!) output from

ip route show
ip link show
ip rule show
iptables -v -L

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: https://lists.debian.org/ibfpo3...@mids.svenhartge.de