Iptables + iproute2 + connmark + 2 Ineterfaces = help to understand, where a mistake

my enviroment https://drive.google.com/open?id=1eZg3RLL7Okx2ZI5hdIpiAae7v2ZQBUbDZndP-b87qzI&authuser=0

opensuse13.1
Device Eth0: 94.45.41.10
VLAN123 (use eth0 ) = 94.45.50.82 ( VLAN123:0=94.45.50.83…VLAN123:2=94.45.50.85 )

Problem
how to create such route for packages from 192.168.43.10 :
192.168.43.10–>192.168.43.8-over eth0 from 94.45.41.10 -->ISP---->to VLAN123=94.45.50.82—>192.168.41.150

I made it so, but doesn’t work:

 cat /etc/iproute2/rt_tables
#
# reserved values
#
255    local
254    main
253    default
0    unspec
#
# local
#
#1    inr.ruhep
# enp3s1
201    TT0
# vlan1325
202    TT1

# enp3s1
VLAN1324="vlan1325"
INET_IFACE="eth0"
LAN_IFACE="eth1"
LAN_IFACE2="eth2"
ip route add     94.45.41.8/30 dev eth0 src 94.45.41.10 table TT0
ip route add default via 94.45.41.9 table TT0
# vlan1325
ip route add     94.45.50.80/29 dev vlan1325 src 94.45.50.82 table TT1
ip route add default via 94.45.50.81 table TT1

ip rule add from 94.45.41.10 table TT0
ip rule add from 94.46.50.82 table TT1
ip rule add from 94.46.50.83 table TT1
ip rule add from 94.46.50.84 table TT1
ip rule add from 94.46.50.85 table TT1
ip rule add from 94.46.50.86 table TT1

ip rule add fwmark $MRK1 table TT0
ip rule add fwmark $MRK2 table TT1

$IPTBL -t mangle -A FORWARD  -i $VLAN1325 -m state --state NEW -j CT1
$IPTBL -t mangle -A FORWARD  -i $INET_IFACE -m state --state NEW -j CT1

$IPTBL -t mangle -A CT1 -i $INET_IFACE -j CONNMARK --set-mark $MRK1
$IPTBL -t mangle -A CT1 -i $VLAN1325   -j CONNMARK --set-mark $MRK2

$IPTBL -t mangle -A PREROUTING -i $LAN_IFACE  -m state --state ESTABLISHED -j CONNMARK --restore-mark
$IPTBL -t mangle -A PREROUTING -i $LAN_IFACE2 -m state --state ESTABLISHED -j CONNMARK --restore-mark

$IPTBL -t mangle -A PREROUTING -i $LAN_IFACE -m connmark --mark 0 -s 192.168.41.150 -j MARK --set-mark $MRK2

$IPTBL -t mangle -A PREROUTING -i $LAN_IFACE2 -m connmark --mark 0 ! -d 192.168.41.0/24 -j MARK --set-mark $MRK1

$IPTBL -t nat -A PREROUTING -i $VLAN1325 -d $94.45.50.85 -p tcp --dport 443  -j DNAT --to-destination 192.168.41.150:443

$IPTBL -A FORWARD -i $VLAN1325 -d 192.168.41.150 -p tcp --dport 443 -j ACCEPT
$IPTBL -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTBL -A FORWARD -i $LAN_IFACE2 -j ACCEPT

$IPTBL -t nat -A POSTROUTING  -o $VLAN1325 -s 192.168.41.150  -j SNAT --to 94.45.50.85
$IPTBL -t nat -A POSTROUTING  -o $INET_IFACE   -j SNAT --to 94.45.41.10


It works:
All outgoing packets from the 192.168.41.150 to the Internet over VLAN325 - OK
Incoming packets from the Internet to the 94.45.50.85:443 -->192.168.41.150:443 - OK
All Outgoing packets from the 192.168.43.10 to the Internt ovet INET_IFACE - OK

it doesn’t work:
Outgoing packets from the 192.168.43.10 to the 94.45.50.85:443 don’t go through INET_IFACE to the Internet.
These packages don’t go anywhere, except the eth2 interface.

PLease, Help me.

Serg

Your rules only translate packets came in via vlan. You probably want to add second rule to DNAT packet to address 94.45.50.85 also from interface eth0 as well as any other rule that allows forwarding etc.

Thanks for the help. it didn’t help…
Now a problem in other place.
Problem is: "How Packets Traverse The Filters "
"

  1. When a packet comes in (say, through the Ethernet card) the kernel first looks at the destination of the packet: this is called `routing’.
  2. If it’s destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it.

"

In my case:
Step1: WS 192.168.43.36 send packets to the 95.45.50.85:tcp:443 ( 192.168.43.8 - default gw for WS)
Step2: In the Linux Server a packet from the WS comes in…
Step3: In the Linux Server “the kernel first looks at the destination of the packet: this is called `routing’.
How the kernel does it? - in the table “local” the kernel looks for records for Destinatin IP Address.
In my case:

 # **ip route show table local**
...........................
broadcast 94.45.41.8 dev enp3s1  proto kernel  scope link  src 94.45.41.10 
local 94.45.41.10 dev enp3s1  proto kernel  scope host  src 94.45.41.10 
broadcast 94.45.41.11 dev enp3s1  proto kernel  scope link  src 94.45.41.10 
broadcast 94.45.50.80 dev vlan1325  proto kernel  scope link  src 94.45.50.82 
local 94.45.50.82 dev vlan1325  proto kernel  scope host  src 94.45.50.82 
local 94.45.50.83 dev vlan1325  proto kernel  scope host  src 94.45.50.82 
local 94.45.50.84 dev vlan1325  proto kernel  scope host  src 94.45.50.82 
l**ocal 94.45.50.85 dev vlan1325  proto kernel  scope host  src 94.45.50.82 **
local 94.45.50.86 dev vlan1325  proto kernel  scope host  src 94.45.50.82 
broadcast 94.45.50.87 dev vlan1325  proto kernel  scope link  src 94.45.50.82 
............
# 


     As you(and linux kernel) can see - 94.45.50.85 is a LOCAL IP ADDRESS

Step4: “the packet passes downwards in the diagram, to the INPUT chain

As Result - the packet doesn’t get to FORWARD chain " -t nat -A PREROUTING"
I try to find how to bypass it…

Serg

DNAT should happen before any routing decisions. Linux netfilter Hacking HOWTO

please excuse me. I didn’t understand, which rule.

It sounds like you have a working machine with address 192.168.41.150
but
You’re having problems with a machine with address 192.168.43.10

Are these two machines on the same network (ie subnet mask 255.255.0.0)?
And, are these two machines on the same physical network?

If so, then I assume that the GW address and any VLAN configuration would be similar if not identical.

You only posted the routing table and the interface configuration for the machine that doesn’t work. Depending on how similar the networking of machine that does work is, perhaps you should compare the two machine configurations.

You also did not post the “ip addr” of each machine. It can be helpful to look not just at the interface configurtion but the working result… which is what “ip addr” does.

Also, would inspecting the regular routing table help with the simple “route” command? Perhaps it would be useful to insert a routing table entry for the remote network using a VLAN address. Like my suggestion using the “ip addr” command, in general it looks like your primary focus is only in the configuration files without inspecting the working result.

At least you have a working machine to compare with. Inspecting what is different between the two should lead you to the correct solution on your non-working machine.

Speculating a bit,
TSU