Re: GRE-NAT broken - SOLVED

Grant Taylor <[email protected]>
Newsgroups org.kernel.vger.lartc
Message-ID <[email protected]>
On 01/30/2018 03:37 PM, Grant Taylor wrote:
> It seems as if something is intercepting the packets.  -  I doubt that 
> it's the NAT module, but I can't rule it out.

Well, I think I ran into the same problem in my tests.

Spoiler:  I did manage to overcome it.

I think the Connection Tracking was part of my (initial?) problem.

> Wait.  tcpdump shows that packets are entering one network interface but 
> they aren't leaving another network interface?

I was seeing this behavior too.

> That sounds like something is filtering the packets.

I think connection tracking (thus NAT) was (at least) part of the culprit.

> I feel like the kicker is that the traffic is never making it out of the 
> local system to the far side.  As such the far side never gets anything, 
> much less replies.

I don't know if this was the case for my testing or not.  I did all of 
my testing from the far side in.

> Ya, the [UNREPLIED] bothers me.  As does the fact that you aren't seeing 
> the traffic leaving the host's external interface.

The [UNREPLIED] was the kicker for me.

> I'd look more into the TRACE option (target) that you seem to have 
> enabled in the raw table.  That should give you more information about 
> the packets flowing through the kernel.

I ended up not using TRACE.

I'm not sure why I did a "conntrack -D", but as soon as I did, my long 
running ping started working.

Upon retesting I can confirm that "conntrack -D" was required to make 
things work.

Further testing and using "conntrack -L" showed that there were some 
connection tracking states that were in an [UNREPLIED] state.  I think 
that "conntrack -D" cleared the stale connections and allowed things to 
start working.

> My hunch is that the packets aren't making it out onto the wire for some 
> reason.  Thus the lack of reply.

After the testing that I did, I suspect that packets did make it onto 
the wire, but were swallowed by connection tracking, thus NAT as you had 
originally thought.

> I'll see if I can't throw together a PoC in Network namespaces this 
> evening to evaluate if NATing GRE works.  -  I'd like to test NATing 
> different sets of endpoints (1:1) and NATing multiple remote endpoints 
> to one local endpoint (many:1).

I threw together a Proof of Concept using Network Namespaces, using a 
pair of OVSs (bri1 & bri2) and a pair of vEths (between R3 / R2 and R2 / 
R1).

I was able to establish a initially establish a GRE tunnels between H1 / 
H3 and H2 / H4.

After figuring out the the connection tracking problem I was also able 
to bring up additional GRE tunnels between H1 / H4 and H2 / H3.

Take a look at the attached GRE-NAT.sh script.  -  I do take some 
liberties and set up aliases to make things easier.  (Read: I'm lazy and 
don't want to type any more characters than I have to.)

alias vsctl='ovs-vsctl'
alias h1='ip netns exec h1'
alias h2='ip netns exec h2'
alias h3='ip netns exec h3'
alias h4='ip netns exec h4'
alias r1='ip netns exec r1'
alias r2='ip netns exec r2'
alias r3='ip netns exec r3'

The network between:

H1 / H2 / R3 is Test-Net-1, 192.0.2.0/24
R3 / R2 is Test-Net-2, 198.51.100.0/24
R2 / R1 is Test-Net-3, 203.0.113.0/24
R1 / H3 / H4 is RFC 1918 private, 192.168.0.0/24

I addressed the GRE tunnels as RFC 1918 private, 10.<Left #>.<Right 
#>.<Device #/24.

R3 & R1 are numbered the way that they are so that their device # 
doesn't conflict with something local.

I did manage to get the PoC to work without needing to issue the 
"conntrack -D" command by simply moving the NAT rules earlier in the 
script before I tried to establish the tunnels.

I can only surmise that there was some sort of bad state that connection 
tracking learned that couldn't fix itself.  -  This was sort of random 
and unpredictable, much like what you're saying.  -  It also likely has 
to do with what end talks first.

I found that I could get things to start working if I issued the 
following command:

(ip netns exec) r1 conntrack -D

Ultimately I was able to issue the following commands:

h1 ping -c 4 10.1.3.3
h1 ping -c 4 10.1.4.4

h2 ping -c 4 10.2.3.3
h2 ping -c 4 10.2.4.4

h3 ping -c 4 10.1.3.1
h3 ping -c 4 10.2.3.2

h4 ping -c 4 10.1.4.1
h4 ping -c 4 10.2.4.2

I /think/ that this is what you were wanting to do.  And, I think you 
were correct all along in that NAT ~> connection tracking was in fact 
messing with you.

Anyway, have fun with the PoC.  Ask if you have any questions about what 
/ why / how I did something.

Oh, ya, I did have the following GRE related modules loaded:

# lsmod | grep -i gre
nf_conntrack_proto_gre    16384  0
nf_nat_proto_gre          16384  0
ip_gre                    24576  0
ip_tunnel                 28672  1 ip_gre
gre                       16384  1 ip_gre

I'm running kernel 4.9.76-gentoo-r1.

> You might be onto something about the first packet.  At least as far as 
> what connection tracking sees.

I think the kicker has to do with connection tracking learning state on 
the first packet.



-- 
Grant. . . .
unix || die
GRE-NAT.png (image/png, 6.6 KB) - not displayed
GRE-NAT.sh (application/x-sh, 3.4 KB)
alias vsctl='ovs-vsctl'
alias h1='ip netns exec h1'
alias h2='ip netns exec h2'
alias h3='ip netns exec h3'
alias h4='ip netns exec h4'
alias r1='ip netns exec r1'
alias r2='ip netns exec r2'
alias r3='ip netns exec r3'
ip netns add h1
ip netns add h2
ip netns add h3
ip netns add h4
ip netns add r1
ip netns add r2
ip netns add r3
vsctl add-br bri1
vsctl add-br bri2
vsctl add-port bri1 h1 -- set interface h1 type=internal
vsctl add-port bri1 h2 -- set interface h2 type=internal
vsctl add-port bri1 r3 -- set interface r3 type=internal
vsctl add-port bri2 h3 -- set interface h3 type=internal
vsctl add-port bri2 h4 -- set interface h4 type=internal
vsctl add-port bri2 r1 -- set interface r1 type=internal
ip link set h1 netns h1
ip link set h2 netns h2
ip link set h3 netns h3
ip link set h4 netns h4
ip link set r1 netns r1
ip link set r3 netns r3
ip link add r2 type veth peer name r3
ip link set r2 netns r3
ip link set r3 netns r2
ip link add r2 type veth peer name r1
ip link set r2 netns r1
ip link set r1 netns r2
h1 ip link set lo up
h1 ip link set h1 up
h2 ip link set lo up
h2 ip link set h2 up
h3 ip link set lo up
h3 ip link set h3 up
h4 ip link set lo up
h4 ip link set h4 up
r1 ip link set lo up
r1 ip link set r1 up
r1 ip link set r2 up
r2 ip link set lo up
r2 ip link set r1 up
r2 ip link set r3 up
r3 ip link set lo up
r3 ip link set r3 up
r3 ip link set r2 up
h1 ip addr add 192.0.2.1/24 dev h1
h2 ip addr add 192.0.2.2/24 dev h2
h3 ip addr add 192.168.0.3/24 dev h3
h4 ip addr add 192.168.0.4/24 dev h4
r1 ip addr add 192.168.0.1/24 dev r1
r1 ip addr add 203.0.113.1/24 dev r2
r1 ip addr add 203.0.113.3/24 dev r2
r1 ip addr add 203.0.113.4/24 dev r2
r2 ip addr add 203.0.113.2/24 dev r1
r2 ip addr add 198.51.100.2/24 dev r3
r3 ip addr add 198.51.100.3/24 dev r2
r3 ip addr add 192.0.2.3/24 dev r3
h1 ip route add default via 192.0.2.3
h2 ip route add default via 192.0.2.3
h3 ip route add default via 192.168.0.1
h4 ip route add default via 192.168.0.1
r1 ip route add default via 203.0.113.2
r2 ip route add 192.0.2.0/24 via 198.51.100.3
r3 ip route add 203.0.113.0/24 via 198.51.100.2

r1 iptables -t nat -A PREROUTING -d 203.0.113.3 -p 47 -j DNAT --to-destination 192.168.0.3
r1 iptables -t nat -A PREROUTING -d 203.0.113.4 -p 47 -j DNAT --to-destination 192.168.0.4
r1 iptables -t nat -A POSTROUTING -s 192.168.0.3 -d 192.0.2.1 -p 47 -j SNAT --to-source 203.0.113.3
r1 iptables -t nat -A POSTROUTING -s 192.168.0.4 -d 192.0.2.2 -p 47 -j SNAT --to-source 203.0.113.4

h1 ip tunnel add h3 mode gre local 192.0.2.1 remote 203.0.113.3
h1 ip link set h3 up
h1 ip addr add 10.1.3.1/24 dev h3
h1 ip tunnel add h4 mode gre local 192.0.2.1 remote 203.0.113.4
h1 ip link set h4 up
h1 ip addr add 10.1.4.1/24 dev h4

h2 ip tunnel add h3 mode gre local 192.0.2.2 remote 203.0.113.3
h2 ip link set h3 up
h2 ip addr add 10.2.3.2/24 dev h3
h2 ip tunnel add h4 mode gre local 192.0.2.2 remote 203.0.113.4
h2 ip link set h4 up
h2 ip addr add 10.2.4.2/24 dev h4

h3 ip tunnel add h1 mode gre local 192.168.0.3 remote 192.0.2.1
h3 ip link set h1 up
h3 ip addr add 10.1.3.3/24 dev h1
h3 ip tunnel add h2 mode gre local 192.168.0.3 remote 192.0.2.2
h3 ip link set h2 up
h3 ip addr add 10.2.3.3/24 dev h2

h4 ip tunnel add h1 mode gre local 192.168.0.4 remote 192.0.2.1
h4 ip link set h1 up
h4 ip addr add 10.1.4.4/24 dev h1
h4 ip tunnel add h2 mode gre local 192.168.0.4 remote 192.0.2.2
h4 ip link set h2 up
h4 ip addr add 10.2.4.4/24 dev h2
smime.p7s (application/pkcs7-signature, 3.9 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.