Comment 9 for bug 1576674

I can't tell from the information that you have given, but I suspect that you have two return paths for packets from the containers.

I don't have the same network topology as you - I only have:
[my machine] <--> switch <--> [MAAS machines]

It sounds like you have:
[your machine] <--> gateway <--> switch <--> [MAAS machines]

So, unsurprisingly, I don't have any problems getting to my guests since my machine is on the same subnet as the MAAS ones. The routing tables for guests only have one route configured per IP address they are responding to and one default route:

ubuntu@juju-machine-0-lxc-0:~$ ip -d route
unicast default via 192.168.1.1 dev eth0 proto boot scope global
unicast 192.168.1.0/24 dev eth1 proto boot scope link
unicast 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.109

This container has two NICs:
ubuntu@juju-machine-0-lxc-0:~$ ip -d addr
<snip loopback>
16: eth0@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:b0:0c:a2 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0
    veth
    inet 192.168.1.108/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:feb0:ca2/64 scope link
       valid_lft forever preferred_lft forever
18: eth1@if19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:52:78:3d brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0
    veth
    inet 192.168.1.109/24 brd 192.168.1.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe52:783d/64 scope link
       valid_lft forever preferred_lft forever

The second route (without the src) will return traffic received on eth1, while the third route will return traffic received on eth0.

It looks like you have an extra route in 4/lxd/3 so you can return traffic on eth0 or eth1 - unfortunately "route -n" isn't much use here because it doesn't tell us about source interfaces.

If your gateway is dropping traffic that is responding on a different MAC address that the connection was initiated on, that would explain the problem you are seeing.

I don't know if Juju has done anything to the routing tables that would cause this. /etc/network/interfaces, if parsed one interface at a time, should be fine. I don't remember why we go to so much trouble with pre and post rules to set up addresses and routes, but it looks odd.