Marc Vorwerk wrote: > > Hello together, > > we have one problem here, it is more an idealistic problem: > > We have an PC - let us call him PC_1 - with one Ethernet adapter. This one is connected to the WWW with this adapter and also via several iptunnels > to an specific PC_2 out there. Through these tunnels now IP packets with private IPaddresses reach PC_1. There they will now be routed by the default > route to the WWW and so they leave eth0 and will be masqueraded ... > > So on PC_1 we did: > > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > > defining the tunnel back to PC_2: > ip tunnel add tunl-4 mode ipip local <IP_form_PC_1> remote <IP_from_PC_2> tos inherit > ip address add 192.168.104.1 dev tunl-4 > ip link set dev tunl-4 up > ip route add default dev tunl-4 table 4 > > this is not so important now: > tc class add dev eth0 parent 20:1 classid 20:2 cbq bandwidth 1000000 rate 9000 allot 1514 weight 900 maxburst 20 avpkt 1000 isolated bounded > tc qdisc add dev eth0 parent 20:2 sfq quantum 1514b perturb 15 > tc filter add dev eth0 parent 20:0 protocol ip pref 2 u32 match u8 2 0xff at 21 flowid 20:2 > > what should be put back in the tunnel to PC_2: > ip rule add fwmark 2 pref 2 table 4 > ip route flush cache > > example for a ping: > iptables -A PREROUTING -t mangle -d <private_IP_that_had_come_out_of_the_tunnel, eg 192.168.199.10> -s <destinationIP_of_server_in_the_WWW> > -p icmp -j MARK --set-mark 2 > iptables -A PREROUTING -t mangle -m mark --mark 2 -j ACCEPT Your assumption is not correct about the dst of these packets. In the mangle table the dst would be PC_1 as you yourself experienced. > > NOW the problem is that the returning IPpackets from the server in the WWW has the destination of PC_1 so the PREROUTING fails :O| > No, this doesn't make sense either. What you could do is to assign a second IP to your WWW and MASQ connections destined for that IP. This way you can mark the packets based on the src (WWW's second IP). Ramin > So we had the idea to set up a dummy0 device and send all demasqueraded IPpackets to this dummy, because we know this must be a private IP: > ip address add 192.168.4.1 dev dummy0 > ip link set dev dummy0 up > ip route add 192.168.199.0 dev dummy0 > > > So the idea was now that the PREROUTING should fetch the incoming packets from dummy0, but it did not work :o( > > Do you have an idea to map the PREROUTING to a special (virtual) device - in this case the dummy0 - or to change the order of Demasquerading and > PREROUTING? > > I know that this whole set-up will work if I use a 3rd machine for the MASQUERADING, but this is really not smart .... > > Thanks a lot for some hints and regards from Aachen, > Marc, Heiko and Colin > >
