2

I read quite some information about the subject lately - because I'm really not used to work at such "low layers" - but I can't point the finger on what I'm doing wrong. Believe me, I tried ;)

I would like to connect a cloud server as it was part of our corporate LAN.

I decided to create a layer 2 bridge (br0), the main reason being that I need to receive broadcasted packets from the LAN in order for an appliance to been seen by the cloud server.

I created a route on the cloud server to direct the LAN subnet through the tap0 interface.

All iptables and ebtables have a default policy of ACCEPT (edit: there are no rules defined and are even disabled).

ARP table on the LAN client shows the cloud server IP/MAC entry.

I can ping br0 from the cloud and I can ping the cloud machine's tap0 (statically defined IP in the client subnet) from the LAN client.

When I do a tcpdump on both interfaces (cloud tap0 and LAN br0), I can seen LAN traffic (STP, IP, ARP, ...) flowing.

This is where things cease to be great: I can't reach other machines on the LAN (when I ping the LAN gateway I get "Destination Host Unreachable". I've got no reply when I do the test with other LAN computers).

PS : don't make me install OpenVPN ^^

edit:

$ bridge link

2: eth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 
4: tap0 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100
$ brctl show

bridge name     bridge id               STP enabled     interfaces
br0             8000.00155da90b0b       no              eth0
                                                        tap0
$ ip link

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 8e:15:41:dc:70:b0 brd ff:ff:ff:ff:ff:ff
11: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:a9:0b:0b brd ff:ff:ff:ff:ff:ff
2
  • If the problem is hidden in configuration details, it would be hard to find it without seing any network configuration. FWIW, "Destination Host Unreachable" usually happens when an ARP request fails after an usual timeout of probably 3s. also iptables rules and ebtables rules: are they empty? Does it work if they are really completely empty?
    – A.B
    Mar 21, 2020 at 12:38
  • @A.B Thanks for your reply! I totally get your point. iptables and etables are completely empty ATM. I already disabled bridge-nf-call-{arp,ip,ip6}tables just in case. Mar 21, 2020 at 13:58

1 Answer 1

0

After all those hours, I was pretty confident that what I was doing was not too far off.

I decided to connect the same cloud instance to a new host in my home LAN. It worked without any particular problem.

I'm still not sure about what is causing the initial issue (an expensive piece of equipment in the corporate network, maybe?), but at least I know this does not come from me :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .