this week we updated our asg8-clusters to utm9 and since then we are getting into troubles with some specific connections.
setup:
utm9:
eth0: 10.0.1.1/24 (no link, ha-link-watch disabled, just for emergency management with notebook)
eth1: 212.x.x.x (external, default gw)
eth2: some vlan interfaces, one with the ip 10.112.0.1/24
client1 (openvz container):
eth0: 10.112.0.x
venet0: 10.111.0.x (default gw on this openvz-ppp-connection)
client2:
eth0: 192.168.228.x
on client1 i set up a route to 192.168.228.x via 10.112.0.1 on interface eth0. usally the connections between client1 and client2 are working without problems.
since the update to utm9 we got problems with some ajax apps in the web browser (e.g. webmail) or e.g. with starting x-forwarded apps in a ssh session between client1 and client2 - suddenly the connections hang and don't continue.
with wireshark i tracked up some of these connections and there was a "fragmentation needed" icmp package sent from the astaro to the client. strange is: the source ip of this packet is 10.0.1.1 - an ip which is in no kind involved in this connection.
consequently it seems client1 doesn't know what to with this packet because it has no known route (matching to the connection) to it. if a add a route to this unused ip/network it will work again, but this can be at temporary workaround at the most.
if i disable eth0 on the utm9, the source ip of the "fragmentation needed" packet will be 212.x.x.x from eth1, which is also not involved in the connection.
why doesn't the utm9 use the source ip of the used gateway interface 10.112.0.1?
This thread was automatically locked due to age.