Thanks for the reply. > check you source routing address with this command: > ip route get 8.8.8.8 I did not know this trick, very useful! But unfortunately my machine is a mac, so can’t use that. > after this, you need rewrite your firewall rules in a OUTPUT chain: > iptables -t nat -I OUTPUT -s $SRC_ADDRESS -d 8.8.8.8 -p udp > --dport 53 -j DNAT --to-destination 127.0.0.1 I tried that, doesn’t seem to work. I even removed the "-s $SRC_ADDRESS” flag to make sure it matches, but it didn’t prevent me from querying 8.8.8.8 on my machine (I have shut down the local dns forwarder, so if this rule were matched, I shouldn’t be able to query 8.8.8.8 at all) I don’t quite understand why I should use the OUTPUT chain. In my mind, the packets flow like this, please correct me if it’s not right: on my mac, ipsec0 interface is the default gateway #1 client ip inside tunnel -> 8.8.8.8 | | client kernel wraps it in ipsec v #2 client public ip -> server public ip | | server kernel unwraps it from ipsec v #3 client ip inside tunnel -> 8.8.8.8 | | server forwards it by doing nat v #4 server public ip -> 8.8.8.8 At #3, it should reenter the ip stack and go through the nat prerouting chain. On 29 Jan 2018, at 8:25 PM, Humberto Jucá <betolj@xxxxxxxxx> wrote: Hi Glen Huang, I have an IPSec tunnel set up between my machine and a server. - check you source routing address with this command: ip route get 8.8.8.8 "So, replace your source address to *src ip address*" But after dig @8.8.8.8 google.com on my machine, running grep 'TRACE:' /var/log/kern.log on the server returned nothing. - after this, you need rewrite your firewall rules in a OUTPUT chain: iptables -t nat -I OUTPUT -s $SRC_ADDRESS -d 8.8.8.8 -p udp --dport 53 -j DNAT --to-destination 127.0.0.1 "Because you are redirecting your internal traffic, use OUTPUT chain." 2018-01-29 7:07 GMT-03:00 Glen Huang <heyhgl@xxxxxxxxx>: (Previous message seems to get smudged. This is a resent.) Hi, Hope the question isn’t too basic to be asked here. I have an IPSec tunnel set up between my machine and a server. All packets originate from my machine go through that tunnel and then get forwarded by the server. I’m trying to redirect DNS request from my machine to 8.8.8.8 to a dns forwarder running on the server. I tried this on the server iptables -t nat -I PREROUTING -s $IPSEC_VIRTUAL_IP -d 8.8.8.8 -p udp --dport 53 -j DNAT --to-destination 127.0.0.1 But it didn't work. To make sure it wasn't because I hadn't allowed martian packets or anything. I tried to trace the decrypted packets. iptables -t raw -I PREROUTING -s $IPSEC_VIRTUAL_IP -d 8.8.8.8 -p udp --dport 53 -j TRACE But after dig @8.8.8.8 google.com on my machine, running grep 'TRACE:' /var/log/kern.log on the server returned nothing. According to this picture: https://en.wikipedia.org/wiki/Iptables#/media/File:Netfilter-packet-flow.svg after decrypting the ipsec packets, netfilter will make the decrypted packets go through the ip stack again, and the trace target should be able to catch it. I wonder if my mental model is incorrect or I missed something? Regards, Glen On Mon, Jan 29, 2018 at 5:10 PM, Glen Huang <heyhgl@xxxxxxxxx> wrote: Hi, Hope the question isn’t too basic to be asked here. I have an IPSec tunnel set up between my machine and a server. All packets originate from my machine go through that tunnel and then get forwarded by the server. I’m trying to redirect DNS request from my machine to 8.8.8.8 to a dns forwarder running on the server. I tried this on the server iptables -t nat -I PREROUTING -s $IPSEC_VIRTUAL_IP -d 8.8.8.8 -p udp --dport 53 -j DNAT --to-destination 127.0.0.1 But it didn't work. To make sure it wasn't because I hadn't allowed martian packets or anything. I tried to trace the decrypted packets. iptables -t raw -I PREROUTING -s $IPSEC_VIRTUAL_IP -d 8.8.8.8 -p udp --dport 53 -j TRACE But after dig @8.8.8.8 google.com on my machine, running grep 'TRACE:' /var/log/kern.log on the server returned nothing. According to this picture: https://en.wikipedia.org/wiki/Iptables#/media/File:Netfilter-packet-flow.svg after decrypting the ipsec packets, netfilter will make the decrypted packets go through the ip stack again, and the trace target should be able to catch it. I wonder if my mental model is incorrect or I missed something? Regards, Glen -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
