I understand, is there a way to move the packet back to raw? Like a goto target or jump to table? We prefer not to use NFQUEUE for this. The scenario we target is Multitenant NAT routing, whereas we have overlapping inside subnets and they need to get to outside using a single NAT instance. We have had luck in almost all cases except in case two inside overlapping IPs, try to reach the same destination IP:port and by bad luck, they chose the same source port. In that case, we see the new SYN packet overwriting the ESTABLISHED session of the other overlapping IP, sending an RST since the ACK no. doesn't match and establishing a new TCP session; making the first overlapping IP unaware of the situation since it never received a RST or anything, the thing keeps retransmitting the same packet and the destination ignores it because there is no SEQ no. associated with it. On Wed, May 29, 2019 at 2:49 PM Fatih USTA <fatihusta86@xxxxxxxxx> wrote: > > Hi, > > idea: > Maybe possible with NFQUEU NF_REPEAT function. You must write your > NFQUEUE application and match traffic inside the app and repeat mark. > > Not tested (maybe more complicated from this) > -A PREROUTING -m mark ! --mark 0x2 -j NFQUEUE --queue-balance 0:3 > --queue-bypass --queue-cpu-fanout > -A PREROUTING -m mark --mark 0x2 -j CT --zone 2 > > NF_REPEAT: packet is reinjected at start of the hook after the verdict > > On Wed, May 29, 2019 at 7:33 PM Felipe Arturo Polanco > <felipeapolanco@xxxxxxxxx> wrote: > > > > Hi, > > > > We have a specific scenario where we need to use conntrack zones along > > with connmarks. > > > > In our tests we saw that connmarks are fully restored in mangle table, > > but we need them available in raw table in order to assign the > > corresponding zone: > > > > eg: > > iptables -t raw -I PREROUTING -j CONNMARK --restore-mark > > iptables -t raw -A PREROUTING -m mark --mark 2 -j CT --zone 2 > > > > Sadly, we haven't been able to make this work, by looking at the TRACE > > log, the mark is not restored in raw table, but in mangle table. > > Since mangle table already happens after conntrack processing, we > > cannot assign the zone. > > > > Any idea how we can approach this? > > > > Thanks,
