"double bridge" setup will only work for 5 minutes

[qupfer]

Hi,

i have some trouble with my "double bridge" setup. It works well for 5 minutes, and then, no more packets between vpn client and server are exchanged.

The setup is not very compicated, but maybe a bit "individuell *g

The softether server is configured to bridge to a tap_device (tap_soft).
On the vpn-server, i create a second bridge between eth0 and tap_soft.
The advantage of this setup is, that I can reach the vpn server though the vpn.
But after some time, the connection will not work anymore. (but the vpn-connection itself is connected)
For example, the "ping" from home-device --> vpn client will change:

64 bytes from 10.10.10.139: icmp_seq=148 ttl=128 time=40.9 ms
64 bytes from 10.10.10.139: icmp_seq=149 ttl=128 time=41.2 ms
From 10.10.10.115 icmp_seq=175 Destination Host Unreachable
From 10.10.10.115 icmp_seq=176 Destination Host Unreachable

or from vpn-client --> vpn server
...
Antwort von 10.10.10.100: Bytes=32 Zeit=36ms TTL=64
Zeitüberschreitung der Anforderung. (<-- "timeout")
...

Has somebody any idea, what could be the reason for this problem?

[dajhorn]

Pastebin the server_log/vpn_XXXXXXXX.log file for the error and check it for messages regarding traffic rate limiting.

This kind of failure can happen during a broadcast loop.

[qupfer]

Hi, thanks for your response.

Here are the last lines of the server.log: http://pastebin.com/ps3vExui
10.10.10.108 is the IP of the Client.

Any suggestions?

[dajhorn]

Rate limiting is happening, but the ethernet interface is also going down. Check these things:

* Is the PHY resetting?
* Is the SoftEther process crashing?
* Does the server have bad memory?

Check the system logs, like /var/log/syslog and /var/log/dmesg for hardware faults.

* Is the bridged ethernet interface managed by something like NetworkManager or by a desktop helper?

If the bridged interface does not have an IP address, some network management utilities will periodically reset it. DEB systems sometimes require this in the /etc/network/interfaces file:

auto eth1
iface eth1 inet manual
hwaddress AA:BB:CC:DD:EE:FF

RPM systems have something similar in the sysconfig.

Please don't truncate or modify log files when you post them.

[qupfer]

thanks for your answer....i'm going be crazy

I reboot my pc, clear syslog, dmesg and server.log.
I start vpnserver, start the bridge and just wait. Doing nothing on pc and no connections from a client. Just waiting:

syslog: http://pastebin.com/N02j9RtZ
server.log: http://pastebin.com/dUML70FZ
dmesg is empty.
vpn_server.conf (I removed passwords, cert and key): http://pastebin.com/vYSFzxrM
My interfaces: http://pastebin.com/ixtw1rkt (I also tried stp on)

Obvious, the question is, why tap_soft entered the disabled state (see syslog).
Also strange: If I restart the bridge after the "disabled state" ('ifdown vpn && ifup vpn')
its looks stable. See syslog2: http://pastebin.com/eeDXmkpR

Edit: not clear from syslog2: since 22:35 no new entry (now is 23:19)

[dajhorn]

Do this:

1. Configure ifplugd to ignore the 'tap_soft' interface.
2. Disable the OpenVPN daemon until you get SoftEther working.
3. If the 'vpn' interface is something that was renamed, then revert that change and use the default interface name.
4. Put something like this in the /etc/network/interfaces file:

allow-hotplug tap_soft
iface tap_soft inet [etc...]

Do not use a "auto tap_soft" line for interfaces that SoftEther creates.

SoftEther incompletely plumbs interfaces that it uses, which can confuse things like ifplugd, nm-applet, and NetworkManager.

[qupfer]

dajhorn wrote:
> Do this:
>
> 1. Configure ifplugd to ignore the 'tap_soft' interface.
Can you please explain how?
Edit: I did. It "removes" the ifplugd syslog messages, but after the first start of the bridge, it will go to the disabled state after a few minutes.....

> 2. Disable the OpenVPN daemon until you get SoftEther working.
openvpn isn't installed, so nothing to disable

> 3. If the 'vpn' interface is something that was renamed, then revert that
> change and use the default interface name.
No, its just my name for the bridge. Could rename it to br0.

> Do not use a "auto tap_soft" line for interfaces that SoftEther
> creates.

tap_soft hasn't any entry in my interfaces - except as bridge port for my bridge configuration.


Just do be clear ;)
tap_soft is just softether's thing. I didn't configure it or anything else. But I want to bridge sofethers tap_soft wit eth0 to a new bridge device.

[dajhorn]

> Can you please explain how?

This depends on the Linux distro. (Debian, Ubuntu, something else?)

For troubleshooting, just uninstall ifplugd and/or disable it entirely.


> openvpn isn't installed, so nothing to disable

Okay.

> No, its just my name for the bridge. Could rename it to br0.

I took a second look at the pasted /etc/network/interfaces file:

* The man page suggests that "hwaddress ether" is incorrect syntax. On my personal computer, I use the "hwaddress AA:BB:CC:DD:EE:FF" form.

* Specifying "address 10.10.10.100" twice is certainly a configuration mistake.

* Some versions of the brctl utilties have problems using interfaces created with an underscore character, and are therefore incompatible with SoftEther tap interfaces, which always have a "tap_" prefix.

If you actually want this kind of configuration, then the stanza for the br0 interface must have the "address 10.10.10.100" line and all other interfaces must not. Review the brctl tutorials for an explanation.

However, SoftEther creates this kind of configuration by default for L2 bridging on physical interfaces. The br0 and vpn stanzas in the current /etc/network/interfaces file are redundant and unnecessary if the "VPN" hub in SoftEther is bridged to eth0 on the host.

You'll probably get the desired result if you reduce complexity and use the examples given in the SoftEther documentation.

[qupfer]

dajhorn wrote:
> > Can you please explain how?
>
> This depends on the Linux distro. (Debian, Ubuntu, something else?)
Debian, but I disabled it compleate ;)

> * The man page suggests that "hwaddress ether" is incorrect syntax. On my
> personal computer, I use the "hwaddress AA:BB:CC:DD:EE:FF" form.
I will change it, but my "random" address was used. So, it understand this syntax.

> * Specifying "address 10.10.10.100" twice is certainly a configuration
> mistake.
Not really. If I start the bridge, eth0 will lose their ip-config.


> * Some versions of the brctl utilties have problems using interfaces created with an
> underscore character, and are therefore incompatible with SoftEther tap interfaces,
> which always have a "tap_" prefix.
Mh, maybe this is the problem. But basicly, my setup will work. Only after a reboot, the bridge will stop working after some minutes. If I restart the bridge again, it looks stable. Will test it overnight.


> However, SoftEther creates this kind of configuration by default for L2 bridging on
> physical interfaces. The br0 and vpn stanzas in the current /etc/network/interfaces
> file are redundant and unnecessary if the "VPN" hub in SoftEther is bridged
> to eth0 on the host.
Yeah, but if i bridge it to eth0, I run in the "3.6.11 Error", which mean I can't reach other servies hosted on the vpn-server through a vpn connection.
Of course, NAT or Routing would be an alternativ, but I want also working broadcasts and stuff like that.

> You'll probably get the desired result if you reduce complexity and use the examples
> given in the SoftEther documentation.

Nope, they have all some restrictions. The closet one is the local bridge direct to eth0, but with the 3.6.11 problem. (https://www.softether.org/4-docs/1-manu ... al_Bridges)

But it realy looks like that reset the bridge will "solve" the problem:
1. start vpnserver --> creates tap_soft
2. start bridge (ifup br0) --> bridge eth0 und tap_soft
3. wait....
4. restart bridge (ifdown br0 && ifup br0)

[qupfer]

Yep, the restarted bridge was stable all night long. So, I have my workaround....

[cedar]

Similar problem is reported when the Linux bridging is used with ifupdown tools and SoftEther local-bridge (includes tap-mode).

Please try to exclude the Linux bridge from /etc/network/interfaces managing.
Using bridge-utils may not cause the problem.