To summarize the context, it's an lxd container that always connects as an OpenVpn client.
{wan} <-> {192.168.x.x <-> iptables <-> lxd bridge host 10.0.3.1} <-> {lxd container 10.0.3.3 | openvpn <-> iptables}
In the container there is
- eth0 (ip 10.0.3.3) which is the client interface on an lxd bridge
- tun0 which connects as a client to an OpenVpn server
The host lxd (10.0.3.1) forwards 10.0.3.3 traffic to the external network, iptables always accepts outgoing connections.
The host and the lxd client both have iptables.
I had already done routing on 10.0.3.3 but for incoming port (for example incoming http port to 10.0.3.3 and responses on eth0, not tun0).
So I have a "novpn" routing table with a fwmark number.
My problem now is that I'm trying to do the inverse. Outgoing requests going to port 21 on any remote server must go through eth0 ("novpn" table).
I followed several posts on stackoverflow and integrated this into the iptables of the 10.0.3.3 client. I feel like it's just:
ip rule add fwmark 66 novpn table
ip route add default via 10.0.3.1 dev eth0 novpn table
iptables -t mangle -A PREROUTING -p tcp --dport 21 -j MARK --set-mark 66
iptables -t mangle -A OUTPUT -p tcp --dport 21 -j MARK --set-mark 66
On iptables of 10.0.3.1, I have a rule that accepts forwards from already established and known connections. So bridge should follow and I don't think any other rules are necessary?
But it doesn't work, when I look at tcpdump on the host (10.0.3.1) I see that the packets are sent with the openvpn IP, not 10.0.3.3. There also seems to be a problem with the checksum of sent packets -> cksum 0x1983 (incorrect -> 0xe8ec).
Curiously, when I do tcpdump on the console of the lxd client (10.0.3.3), tcpdump does not display anything and there I no longer understand anything.
I wonder if lxd takes precedence (maybe something like the proxy devices, etc.) over iptables (and tcpdump??), but that seems very weird to me.
If it can be useful, I have a rule "ip rule add to xxx.xxx.xxx.xxx table novpn". So any connection to this ip goes through eth0 and, this is indeed the case, there the request is correct in tcpdump.
Can anybody help me.
