On 30 Jan 2018, at 12:42 AM, Chris Clark <rip057@xxxxxxxxx> wrote:
I honestly rarely get a chance to read and or understand some of these but if you are talking dns, you probably want to deal with the dns resolver on the server or the client, which in most things Linux (idk about iOS) is dnsmasq
On Jan 29, 2018 10:39 AM, "Chris Clark" <rip057@xxxxxxxxx> wrote:
Well good volley,
Use dnsmasq and redirect the address.
Google is your friend...
On Jan 29, 2018 9:09 AM, "Glen Huang" <heyhgl@xxxxxxxxx> wrote:
Sigh, sometimes when you try to defend yourself, you start to look suspicious.
I can see why the question seemed suspect, let me explain myself:
From where I live, the internet is censored and dns cache is poisoned
by default. To counter that, I set up an ipsec vpn, but to speed
things up, I split the connections so when the destination is
domestic, I connect directly. The problem comes when I need to resolve
domains. I do it via 8.8.8.8, but since it goes through the server,
the ips returned from cdns aren't always domestic, thus I lose the
performance gain. I'm trying to stick the edns client subnet value
containing my client public ip into the dns query I send to the
server. Since I'm not always in control of the client wherever I go, I
plan to do it on the server with an ECS capable dns forwarder. I come
up with a couple of solutions:
1. Make the dns forwarder listen on the server's public ip, return
that ip as dns when clients connect vpn, and change the source ip to
client's public ip when the clients query it with in-tunnel ip. But
somehow ipsec only protects forwarded packets, I asked a question on
strongswan mailing list, got no reply yet:
https://lists.strongswan.org/pipermail/users/2018-January/012165.htm
2. Make the dns forwarder listen on the server's loopback's interface,
and when clients query 8.8.8.8, redirect to it and also change the
source ip. This is the case I'm asking.
3. Make the dns forwarder listen on a virtual NIC or an ip alias on
the wan interface. This isn't very different from #1, but I encounter
the same problem as I did in #2: I can't match the dns packets from
ipsec, so there is nothing I can do to them. I figure if I can solve
#2, I should be able to solve #3 also. Thus the question. :)
Maybe #3 would be a better question to ask. Sorry if I made things
complicated. I'll keep the hacker factor in mind in the future.
On Mon, Jan 29, 2018 at 9:53 PM, Chris Clark <rip057@xxxxxxxxx> wrote:
I know how to do this very easily with one line in a file, but this question
seems awefully suspect, as one of those, "hey help me hack a network."
Seriously though, sorry if I offend you, but you should be able to just set
up another dns on the computer and this is something any user of the
machine, your machine, should have access to.
This question is sort of like asking someone how to poison a dns cache.
Thanks but no thanks
On Jan 29, 2018 7:14 AM, "Glen Huang" <heyhgl@xxxxxxxxx> wrote:
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
