Re: Port redirection

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

Hello,

Steve Fink a écrit :
> I am trying to redirect all traffic generated on box $SRC to a
> particular UDP port to a different host $SPY. I've done similar things
> with whole TCP connections using DNAT and SNAT, but this time I want
> UDP and I want to be able to start up the redirection after the
> "connection" has been established. (I never see these packets in the
> 'nat' table.)

You don't see these packets in the 'nat' table because the "connection" 
already exists and has an an entry in the conntrack table. You can 
delete a conntrack entry with the conntrack command from the 
conntrack-tools package. You can also prevent the packets to create a 
conntrack entry by using the NOTRACK target in the 'raw' table until 
after you add the NAT rules. Make sure to match packets in both 
directions. After you remove the NOTRACK rules, the next packet will 
enter the 'nat' chains and hit the NAT rules.

> The only option that seemed viable, me not knowing much about
> networking, was to use the 'mangle' table to set a mark on the
> outgoing packets, then use 'ip' to route the packet to $SPY. I've used
> iptables a fair amount, but ip not at all.
> 
> On $SRC, I ran:
>  iptables -t mangle -A OUTPUT -p udp --dport 8765 -j MARK --set-mark 1
>  ip rule add fwmark 1 table 50
>  ip route add via $SPY table 50
>  sysctl net.ipv4.ip_forward=1 # Dunno if this matters

It doesn't matter. Packets are locally generated, the box does not act 
as a router.

>  ip route flush cache
> 
> On $SPY, I ran:
>  sysctl net.ipv4.ip_forward=1 # Makes sense here
> 
> $SRC, $SPY, and $ORIG_DEST (the original destination) can all reach each other.
> 
> According to iptables, the mark is getting set on the packets I want
> redirected. But tcpdump shows packets still going to the original
> destination, not $SPY. I am testing by running this on $SRC
> 
>   nc -v -u $ORIG_DEST 8765
> 
> And I trigger packets to be sent by hitting enter in that window. The
> packets are making it to my dummy server on $ORIG_DEST. They do not
> show up to tcpdump on $SPY.
> 
> I don't know how to read the output of 'ip route show cache', but it includes
> 
> $SPY from $SRC tos lowdelay dev tun0
>     cache  mtu 1412 advmss 1372 hoplimit 64
> local $SRC from $SPY tos lowdelay dev lo  src $SRC
>     cache <local,src-direct>  iif tun0
> 
> (I'm testing this over a VPN, hence the tun0 device. Both $ORIG_DEST
> and $SPY are accessible via the VPN.)

This matters a lot : for both $ORIG_DEST and $SPY, the actual next hop 
is the VPN endpoint.

> The only thing I can think of is that $SPY needs to be reachable in a
> single hop

Indeed, otherwise the actual next hop will forward the packets based on 
the destination address. Whether the packet is marked or not, the next 
hop is the VPN endpoint anyway, and it forwards the packets to 
$ORIG_DEST, not $SPY.