ipip (gif) tunnels and npf

[John Klos]

Hi,

I've been playing with npf to get more comfortable with it. There really
aren't all that many examples on the Internet to use, so I'm a bit stumped
while trying to get a gif tunnel (ipip protocol) to work.

Of course, gif works across NAT - I've been using gif from behind ipfilter
for ages, and it works behind most other types of NAT, too. However, npf
doesn't seem to want to rewrite ipip traffic.

When I have the internal <-> other side endpoints in gif behind npf, I see
the packets leaving the public interface looking like this:

01:20:16.772680 IP 10.0.100.97 > 74.118.183.200: IP 192.80.49.79 > 192.80.49.78: ICMP echo request, id 3384, seq 0, length 64 (ipip-proto-4)
01:20:17.777222 IP 10.0.100.97 > 74.118.183.200: IP 192.80.49.79 > 192.80.49.78: ICMP echo request, id 3384, seq 1, length 64 (ipip-proto-4)

They're clearly not rewritten.

As a test, I set the endpoint for the gif behind npf to the public address
and saw what I expected:

01:27:02.753125 IP 76.169.240.26 > 74.118.183.200: IP 192.80.49.79 > 192.80.49.78: ICMP echo request, id 564, seq 5, length 64 (ipip-proto-4)
01:27:02.784180 IP 74.118.183.200 > 76.169.240.26: IP 192.80.49.78 > 192.80.49.79: ICMP echo reply, id 564, seq 5, length 64 (ipip-proto-4)

Of course, the npf machine has no idea what to do with this traffic, and I
wouldn't have any idea how to use npf to forward this traffic anyway, but
it shows that everything else is working as it should.

So what needs to be done to get npf to rewrite ipip packets?

Thanks,
John Klos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by John Klos
When I have the internal <-> other side endpoints in gif behind npf, I see
01:20:16.772680 IP 10.0.100.97 > 74.118.183.200: IP 192.80.49.79 > 192.80.49.78: ICMP echo request, id 3384, seq 0, length 64 (ipip-proto-4)
01:20:17.777222 IP 10.0.100.97 > 74.118.183.200: IP 192.80.49.79 > 192.80.49.78: ICMP echo request, id 3384, seq 1, length 64 (ipip-proto-4)
They're clearly not rewritten.

NAT should look at packets on the outgoing interface and these
should be rewritten, wether they are e.g. IP+TCP or IP+IP packets
shouldn't matter.

Some thing like this:

ext_if = pppoe0
ext_ip = inet4($ext_if)
private_net = { 10.0.100.0/24 }

map $ext_if dynamic $private_net -> $ext_ip

should work also for tunnel packets.

[John Klos]

Post by John Klos
01:20:16.772680 IP 10.0.100.97 > 74.118.183.200: IP 192.80.49.79 > 192.80.49.78: ICMP echo request, id 3384, seq 0, length 64 (ipip-proto-4)
01:20:17.777222 IP 10.0.100.97 > 74.118.183.200: IP 192.80.49.79 > 192.80.49.78: ICMP echo request, id 3384, seq 1, length 64 (ipip-proto-4)
They're clearly not rewritten.

NAT should look at packets on the outgoing interface and these should be
rewritten, wether they are e.g. IP+TCP or IP+IP packets shouldn't
matter.

SHOULD, yes. Although I didn't put my config in the original message, it's
exactly what you put and what's in the example configuration. From npfctl
show:

map re0 dynamic any -> 76.169.240.26 pass family inet4 from 10.0.100.0/24

Should I create a PR?

John

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by John Klos

NAT should look at packets on the outgoing interface and these should be
rewritten, wether they are e.g. IP+TCP or IP+IP packets shouldn't
matter.

SHOULD, yes. Although I didn't put my config in the original message, it's
exactly what you put and what's in the example configuration. From npfctl
map re0 dynamic any -> 76.169.240.26 pass family inet4 from 10.0.100.0/24
Should I create a PR?

Of course :)

[Robert Swindells]

Post by John Klos
SHOULD, yes. Although I didn't put my config in the original message, it's
exactly what you put and what's in the example configuration. From npfctl
map re0 dynamic any -> 76.169.240.26 pass family inet4 from 10.0.100.0/24

Don't you want gif0 (or whatever) to be your external interface instead
of re0 ?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Klos]

Post by Robert Swindells

Post by John Klos
SHOULD, yes. Although I didn't put my config in the original message, it's
exactly what you put and what's in the example configuration. From npfctl
map re0 dynamic any -> 76.169.240.26 pass family inet4 from 10.0.100.0/24

Don't you want gif0 (or whatever) to be your external interface instead
of re0 ?

Sorry - the context is in the original post. The gif tunnel is on a
machine which is behind NAT, and the npf machine doing NAT isn't rewriting
ipip.

John

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Swindells]

Post by John Klos

Post by Robert Swindells

Post by John Klos
SHOULD, yes. Although I didn't put my config in the original message, it's
exactly what you put and what's in the example configuration. From npfctl
map re0 dynamic any -> 76.169.240.26 pass family inet4 from 10.0.100.0/24

Don't you want gif0 (or whatever) to be your external interface instead
of re0 ?

Sorry - the context is in the original post. The gif tunnel is on a
machine which is behind NAT, and the npf machine doing NAT isn't rewriting
ipip.

You are correct, npf doesn't have support for encapsulated protocols
while ipf does. This will mean that gre(4) won't work either.

I guess one question is how far we should go to support this in 2017,
there is this thing called IPv6.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Robert Swindells
You are correct, npf doesn't have support for encapsulated protocols
while ipf does. This will mean that gre(4) won't work either.

npf works for IP, and that means gre(4) is supposed to work too.