How to trace IPSec packets?

How to trace IPSec packets?

[Glen Huang]

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

Re: How to trace IPSec packets?

[Glen Huang]

(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@gmail.com> 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

Re: How to trace IPSec packets?

[Humberto Jucá]

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@gmail.com>:
> (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@gmail.com> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to trace IPSec packets?

[Glen Huang]

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@gmail.com> 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@gmail.com>:

(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@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to trace IPSec packets?

[Glen Huang]

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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>:
>
> (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@gmail.com> 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@vger.kernel.org
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: How to trace IPSec packets?

[Glen Huang]

Yes! I’m using dnsmasq, and I’m using its add-subnet option. But the problem is, I can not hard code an ip there, because the client can change. And there might have multiple connected clients with different public ips (share the server to some friends). So I use add-subnet=24, in which case dnsmasq will extract the ip from the requestor ip. If I’m not wrong, in this case I need to change the dns request source ip to client’s public ip, which I can get when vpn is established, but can’t figure out how to match the packets and SNAT them.

> On 30 Jan 2018, at 12:42 AM, Chris Clark <rip057@gmail.com> 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@gmail.com> wrote:
> Well good volley,
> 
> Use dnsmasq and redirect the address.
> 
> Google is your friend...
> 
> On Jan 29, 2018 9:09 AM, "Glen Huang" <heyhgl@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>:
> >
> > (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@gmail.com> 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@vger.kernel.org
> > 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@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >

Re: How to trace IPSec packets?

[Jeff Kletsky]

Glen,

I don't completely understand your objectives, but if you want to 
provide "your own" DNS resolution choices to hosts within your control, 
I'd look into unbound and designating your unbound instance as the 
resolver for hosts on your network. It can make direct queries to the 
root DNS servers, handle local overrides, and deal with fall-back to 
external DNS resolvers when a stub resolver or local data is in use. 
It's a lot cleaner and easier to maintain than all the address spoofing 
that it sounds like you're exploring. unbound also supports DNSSEC.

https://calomel.org/unbound_dns.html -- great overview of capabilities

https://www.unbound.net/



On 1/29/18 8:16 PM, Glen Huang wrote:
> Yes! I’m using dnsmasq, and I’m using its add-subnet option. But the problem is, I can not hard code an ip there, because the client can change. And there might have multiple connected clients with different public ips (share the server to some friends). So I use add-subnet=24, in which case dnsmasq will extract the ip from the requestor ip. If I’m not wrong, in this case I need to change the dns request source ip to client’s public ip, which I can get when vpn is established, but can’t figure out how to match the packets and SNAT them.
>
>> On 30 Jan 2018, at 12:42 AM, Chris Clark <rip057@gmail.com> 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@gmail.com> wrote:
>> Well good volley,
>>
>> Use dnsmasq and redirect the address.
>>
>> Google is your friend...
>>
>> On Jan 29, 2018 9:09 AM, "Glen Huang" <heyhgl@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>:
>>>
>>> (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@gmail.com> 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@vger.kernel.org
>>> 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@vger.kernel.org
>>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to trace IPSec packets?

[Glen Huang]

Jeff, thanks for the suggestion.

I initially gave bind a look, but since I just need edns-client-subnet support, I find dnsmasq to be a more lightweight solution. I think using unbound will lead to the same difficult as I did with dnsmasq: I ultimately need to map client’s in-tunnel ip to client’s public ip when they do dns requests inside ipsec, and I need to stick the public ip in ECS. So doing iptables in inevitable IMHO.

I just found someone looking for the same solution as I do: https://groups.google.com/forum/#!topic/public-dns-discuss/nuQZcMVhcoo

And from his research, it looks like even if I can get ECS to work, it won’t work for all domains, since it also needs authoritative name server’s support. This greatly reduces my interest in making it work.

Thanks for all the help.

> On 31 Jan 2018, at 2:41 AM, Jeff Kletsky <netfilter@allycomm.com> wrote:
> 
> Glen,
> 
> I don't completely understand your objectives, but if you want to provide "your own" DNS resolution choices to hosts within your control, I'd look into unbound and designating your unbound instance as the resolver for hosts on your network. It can make direct queries to the root DNS servers, handle local overrides, and deal with fall-back to external DNS resolvers when a stub resolver or local data is in use. It's a lot cleaner and easier to maintain than all the address spoofing that it sounds like you're exploring. unbound also supports DNSSEC.
> 
> https://calomel.org/unbound_dns.html -- great overview of capabilities
> 
> https://www.unbound.net/
> 
> 
> 
> On 1/29/18 8:16 PM, Glen Huang wrote:
>> Yes! I’m using dnsmasq, and I’m using its add-subnet option. But the problem is, I can not hard code an ip there, because the client can change. And there might have multiple connected clients with different public ips (share the server to some friends). So I use add-subnet=24, in which case dnsmasq will extract the ip from the requestor ip. If I’m not wrong, in this case I need to change the dns request source ip to client’s public ip, which I can get when vpn is established, but can’t figure out how to match the packets and SNAT them.
>> 
>>> On 30 Jan 2018, at 12:42 AM, Chris Clark <rip057@gmail.com> 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@gmail.com> wrote:
>>> Well good volley,
>>> 
>>> Use dnsmasq and redirect the address.
>>> 
>>> Google is your friend...
>>> 
>>> On Jan 29, 2018 9:09 AM, "Glen Huang" <heyhgl@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com>:
>>>> 
>>>> (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@gmail.com> 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@vger.kernel.org
>>>> 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@vger.kernel.org
>>>> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: How to trace IPSec packets?

[Raymond Burkholder]

> I initially gave bind a look, but since I just need edns-client-subnet support, I
> find dnsmasq to be a more lightweight solution. I think using unbound will
> lead to the same difficult as I did with dnsmasq: I ultimately need to map
> client’s in-tunnel ip to client’s public ip when they do dns requests inside
> ipsec, and I need to stick the public ip in ECS. So doing iptables in inevitable
> IMHO.

https://dnsdist.org/index.html is a rules based load balancer with various dns functionality.  Maybe load balancers might be a different question to ask?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.