Zusätzliche öffentliche IPv4-Adresse via GRE-Tunnel

[CoMo]

Hallo,

Ich bekomme von meinem Provider nur eine statische IPv4-Adresse zugewiesen.

Nun möchte ich aber gerne Dienste auf einer weiteren Adresse betreiben, die ich nach Belieben wechseln kann und bin über dieses Angebot gestolpert: https://noez.de/de/flexips

Mit meinem OpenWrt Router scheint das grundsätzlich möglich zu sein.

Verstehe ich das richtig, dass ich den Tunnel konfiguriere und dann via DNAT/SNAT entsprechende Regeln konfiguriere, damit einzelne Geräte über diesen Tunnel laufen? Ist es so einfach? Oder übersehe ich da was? Hat da jemand Erfahrungen?

 

[syhm]

Genau. Ich habe dies manuell auf einen vServer so laufen.

 

[razzy]

du baust mit einem Router zu dem IP-Provider einen GRE Tunnel auf, sodass du deine internen Adressen zum IP-Provider über dein "Internet" tunnelst.
Der IP-Provider müsste dann ein IP-NAT auf die externe Adresse machen.

"GRE Tunnel Pakete" haben natürlich noch einen zusätzlichen Header sprich Overhead zum eigentlichen Traffic und erzeugen damit mehr Traffic auf deiner Leitung respektive es geht nicht soviel durch als wenn du es ohne Tunnel ins "Internet" schickst.

OffTopic:
Im groben funktionieren so auch CloudProxies/CloudFirewalls

 

[CoMo]

So, ich habs bisher leider nicht hinbekommen, das auf meinem Router einzurichten. Der Support ist hilfsbereit, da wird auch schon intern diskutiert, aber auf OpenWRT hat das bisher dort offenbar bisher auch noch niemand konfiguriert. Eventuell ja hier?

Das sind die offiziellen Instruktionen für Linux:

ip tunnel add gre1 mode gre local 80.151.xxx.xxx remote 5.230.xxx.xxx ttl 255
ip addr add 172.16.2.2/30 dev gre1
ip link set gre1 up
ip addr add 5.230.xxx.xxx/32 dev gre1
ip rule add from 5.230.xxx.xxx table 20 prio 1
ip route add default via 172.16.2.1 dev gre1 table 20

Nun möchte ich natürlich nichts am OpenWRT vorbeikonfigurieren, also muss das entweder über LuCi oder über die

/etc/config/network

funktionieren.

In LuCi kann ich zwar einen GRE-Tunnel anlegen und die beiden Endpunkte konfigurieren, jedoch nicht die IP-Adressen. Soweit bin ich am Wochenende nach langem Friemeln gekommen:

config interface 'noez_gre1'
        option proto 'gre'
        option netmask '255.255.255.252'
        option peeraddr '5.230.xxx.xxx'
        option ipaddr '80.151.xxx.xxx'
        option ttl '255'

config route
        option target '5.230.xxx.xxx'
        option interface 'noez_gre1'
        option metric '1'

config route
        option target '192.168.100.138'
        option gateway '172.16.2.1'
        option netmask '255.255.255.255'
        option metric '1'
        option interface 'noez_gre1'

Da fehlen jetzt mindestens die 2 internen IP-Adressen am Interface, die hatte ich aber auch schon mal irgendwie da reingepopelt, funktioniert hat es trotzdem nicht. Ziel ist erst mal, via statischer Route das Gerät mit der IP-Adresse 192.168.100.138 über den Tunnel zu schicken.

Irgendwelche Ideen, wie ich das anstelle?

Falls der Noez Support sich mit einer Lösung meldet, werde ich die natürlich auch hier mitteilen.

 

[Gliese]

1. Funktioniert denn wenigstens die offizielle Instruktionen für Linux?

Leider habe ich aktuell kein OpenWRT zum Ausprobieren, aber mir fällt beim Lesen bereits auf:
2. Du hast deinem Server-Interface 80.151.x.x die Netzmaske 255.255.255.252 (/30) zugewiesen - diese Netzmaske musst du stattdessen auf die 172.16.x.x anwenden.
3. Neben den internen IP-Adressen 172.16.x.x die du bereits erwähnt hast das diese fehlen, vermisse ich auch die Interface-Definition für die 5.230.x.x. Nur eine Route reicht nicht.

4. Außerdem verstehe ich das mit der 192.168.100.138 nicht. Nach meinem Verständnis weiß deine Gegenstelle gar nicht, was es mit der IP auf sich hat - oder hab ich ein Konfigurationsdetail übersehen? Oder ist es eher so zu verstehen: Bei dir ein Computer mit dieser IP und es soll von außen drauf zugegriffen werden? Das wäre dann ein Fall für DNAT.

 

[CoMo]

1. Funktioniert denn wenigstens die offizielle Instruktionen für Linux?

Habe ich gar nicht weiter probiert. Aber da würden mir ja immer noch die passenden Routen oder NAT-Regeln fehlen. Ich gehe davon aus, dass die Instruktionen korrekt sind.

2. Du hast deinem Server-Interface 80.151.x.x die Netzmaske 255.255.255.252 (/30) zugewiesen - diese Netzmaske musst du stattdessen auf die 172.16.x.x anwenden.
3. Neben den internen IP-Adressen 172.16.x.x die du bereits erwähnt hast das diese fehlen, vermisse ich auch die Interface-Definition für die 5.230.x.x. Nur eine Route reicht nicht.

Gute Hinweise. Ja, dass da noch was fehlt, war mir soweit klar. Ich weiß nur noch nicht, wie ich das genau konfiguriere.

4. Außerdem verstehe ich das mit der 192.168.100.138 nicht. Nach meinem Verständnis weiß deine Gegenstelle gar nicht, was es mit der IP auf sich hat - oder hab ich ein Konfigurationsdetail übersehen? Oder ist es eher so zu verstehen: Bei dir ein Computer mit dieser IP und es soll von außen drauf zugegriffen werden? Das wäre dann ein Fall für DNAT.

Das ist eine Windows-VM, die ich erst mal zum Testen installiert habe. Ich erwarte, dass ich mit der Tunnel-IP nach außen kommuniziere, wenn ich in der VM den Browser verwende und dass die VM über meine Tunnel-IP von außen erreichbar ist. Ich dachte, dafür reicht es, der VM als Default-Route das Gateway des Tunnels zuzuweisen. Aber erstens hab ich das offenbar schon mal falsch konfiguriert, zweitens hab ich die Gateway-IP noch keinem Interface zugewiesen und drittens reicht das wohl nicht und ich muss da tatsächlich irgendwas mit DNAT/SNAT basteln. Hm.

 

[syhm]

Ich habe leider auch kein OPENWRT zur Hand. Laut Doku sollte die Config aber so aussehen. Damit deine VM über den Tunnel kommunizieren kann, brauchst du eine SNAT Regel, denn die Gegenstelle (Noez) weiß nichts von dem 192.168.100.0/24 Netz.

config interface 'noez1'
    option proto    'gre'
    option peeraddr '5.230.xxx.xxx'
 
config interface 'noez2'
    option proto    'static'
    option ifname   '@noez1'
    option ipaddr   '172.16.2.2'
    option netmask  '255.255.255.252'

config redirect
    option    name        'SNAT noez'
    option    src_dip    '172.16.2.2'
    option    dest        'noez2'
    option    target    'SNAT'

 

[CoMo]

Also der erste Teil scheint zu funktionieren, ich kann das interne Gateway 172.16.2.1 pingen 👍

Der zweite Teil gehört nicht in die /etc/config/network, sondern in die /etc/config/firewall und LuCi macht mir daraus

config nat
        option target 'SNAT'
        option src 'noez2'
        option name 'SNAT noez'
        option snat_ip '172.16.2.2'

Pinge ich nun meine öffentliche Tunnel-IP aus dem 5.230.x.x Netz, antwortet meine Telekom-WAN-IP mit "Destination Port Unreachable". Also irgendwas fehlt noch

Grüße an den noez Support, die haben diesen Thread beim Googlen auch schon gefunden und lesen gespannt mit 🙃

 

[syhm]

Der Tunnel steht somit schonmal, sehr gut. Gibt es bei Openwrt für das GRE Interface Firewall Regeln?

 

[CoMo]

Möglich, ich finde sie aber nicht. Ich habe das hier gefunden https://openwrt.org/packages/pkgdata_owrt18_6/kmod-nf-nathelper-extra

Extra Netfilter (IPv4) Conntrack and NAT helpers\\ Includes: \\ - amanda\\ - h323\\ - irc\\ - mms\\ - pptp\\ - proto_gre\\ - sip\\ - snmp_basic\\ - tftp\\ - broadcast\\ \\

Und ich habe

net.netfilter.nf_conntrack_helper=1

gesetzt via /etc/sysctl.conf

Weitergebracht hat mich das noch nicht. Muss ich ggfs. eine neue Firewall-Zone anlegen?

So oder so bräuchte ich doch auch eine Rückroute über das 172.16.2.1 Gateway.

Da sehe ich auch nix von proto_gre:

root@omnia:~# lsmod | grep conntrack
nf_conntrack           86016 31 xt_state,xt_nat,xt_helper,xt_conntrack,xt_connmark,xt_connlimit,xt_connbytes,xt_REDIRECT,xt_MASQUERADE,xt_CT,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_flow_table,nf_conntrack_tftp,nf_conntrack_snmp,nf_conntrack_sip,nf_conntrack_pptp,nf_conntrack_netlink,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp,nf_conntrack_broadcast,nf_conntrack_amanda,nf_conncount,nf_nat
nf_conntrack_amanda    16384  3 nf_nat_amanda
nf_conntrack_broadcast   16384  1 nf_conntrack_snmp
nf_conntrack_ftp       16384  3 nf_nat_ftp
nf_conntrack_h323      45056  5 nf_nat_h323
nf_conntrack_irc       16384  3 nf_nat_irc
nf_conntrack_netlink   36864  0
nf_conntrack_pptp      16384  3 nf_nat_pptp
nf_conntrack_sip       28672  5 nf_nat_sip
nf_conntrack_snmp      16384  3 nf_nat_snmp_basic
nf_conntrack_tftp      16384  3 nf_nat_tftp
nf_defrag_ipv4         16384  1 nf_conntrack
nf_defrag_ipv6         20480  1 nf_conntrack
nfnetlink              16384  2 nf_conntrack_netlink,ip_set
x_tables               24576 54 ipt_REJECT,xt_time,xt_tcpudp,xt_tcpmss,xt_statistic,xt_state,xt_recent,xt_nat,xt_multiport,xt_mark,xt_mac,xt_limit,xt_length,xt_hl,xt_helper,xt_ecn,xt_dscp,xt_conntrack,xt_connmark,xt_connlimit,xt_connbytes,xt_comment,xt_TCPMSS,xt_REDIRECT,xt_MASQUERADE,xt_LOG,xt_HL,xt_FLOWOFFLOAD,xt_DSCP,xt_CT,xt_CLASSIFY,iptable_raw,iptable_nat,iptable_mangle,iptable_filter,ipt_ECN,ip_tables,ebtables,ebt_vlan,ebt_stp,ebt_redirect,ebt_pkttype,ebt_mark_m,ebt_mark,ebt_limit,ebt_among,ebt_802_3,xt_set,ip6table_nat,ip6t_NPT,ip6table_mangle,ip6table_filter,ip6_tables,ip6t_REJECT
xt_conntrack           16384 26

 

[syhm]

Ich habe leider keinerlei Erfahrungen bzgl. Openwrt aber wahrscheinlich musst du erst eine Zone einrichten. Wenn der Tunnel steht und die Gegenseite bei noez antwortet passt vom Tunnel her alles soweit. Du kannst ja mal tcpdump auf der CLI für das GRE Interface starten, dort müsstest du die ICMP Pakete sehen wenn du die öffentliche IP pingst.

 

[CoMo]

Also das frisst er:

config rule
        option src 'wan'
        option name 'Allow-GRE'
        option dest 'lan'
        option target 'ACCEPT'
        list proto 'gre'
        option family 'ipv4'

config rule
        option src 'lan'
        option name 'Allow-Outbound-GRE'
        option family 'ipv4'
        option target 'ACCEPT'
        option dest 'wan'
        list proto 'gre'

bringt mich aber noch nicht weiter.

Du kannst ja mal tcpdump auf der CLI für das GRE Interface starten, dort müsstest du die ICMP Pakete sehen wenn du die öffentliche IP pingst.

Ja, der Ping kommt an:

root@omnia:~# tcpdump -i gre4-noez1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre4-noez1, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
22:18:14.458470 IP xxx > 5.230.x.x: ICMP echo request, id 59494, seq 1, length 64
22:18:15.459663 IP xxx > 5.230.x.x: ICMP echo request, id 59494, seq 2, length 64
22:18:16.460410 IP xxx > 5.230.x.x: ICMP echo request, id 59494, seq 3, length 64

 

[Gliese]

Mein Senf dazu:
1. Wenn die Firewall deine GRE-Connection gänzlich blocken würde, dürftest du mit tcpdump -i ...noez... nix empfangen (würde ja am WAN hängen bleiben bevor das GRE-Paket überhaupt verarbeitet wird). Aber da du ja was empfängst -> GRE in Prinzip Ok -> sieht schon mal gut aus.
2. Ich vermisse immer noch irgendeine Stelle, wo du definierst, das ein Netzwerk-Interface die IP 5.230.x.x eingebunden hat.
3. SNAT über Source-IP 172.16.2.2 wird im Internetbetrieb nicht funktionieren, du müsstest schon SNAT mit der Source-IP 5.230.x.x machen und dann den Traffic über den Gateway 172.16.2.1 routen. Der GRE-Tunnel-Service von nouz.de führt nämlich selbst kein NAT durch (in der Beschreibung steht davon nix also gehe ich davon aus dass es eine vollwertige routeable IPv4 ist).
3b. Problem 3 ist zweitrangig - schau erstmal zu dass du dein Tunnel ohne Fehlermeldung pingen kannst, dann kannst du dich um Problem 3 kümmern.

 

[syhm]

Der Tunnel funktioniert doch einwandfrei, Endpunkt lässt sich pingen und die Pakete kommen an. Die Firewall verwirft ankommende Pakete über den Tunnel, weil es keine Zone/Regeln hierfür gibt. Die Doku von Openwrt bietet hier alles was nötig ist und ist ganz gut, allerdings setzt diese gewisse Netzwerk Kenntnisse voraus. So müsste die Konfig funktionieren, die SNAT Regel brauchst du nicht mehr, da über die Zone ein Masquerade für das Interface gesetzt werden kann.

config interface 'noez1'
    option proto    'gre'
    option zone     'noez'
    option peeraddr '5.230.xxx.xxx'

config interface 'noez2'
    option proto    'static'
    option ifname   '@noez1'
    option ipaddr   '172.16.2.2'
    option netmask  '255.255.255.252'

config zone
    option name    'noez'
    option network     'noez2'
    option input       'REJECT'
    option output      'ACCEPT'
    option masq        '1'

config rule
    option    name        'Allow ICMP via noez'
    option    src        'noez'
    option    proto        'icmp'
    option    target        'ACCEPT'

Ergänzung (17. Januar 2023)

2. Ich vermisse immer noch irgendeine Stelle, wo du definierst, das ein Netzwerk-Interface die IP 5.230.x.x eingebunden hat.

Noez leitet den Traffic der auf die 5.230.x.x eingeht per DNAT auf 172.16.2.2 weiter und umgekehrt wird der gesamte Traffic der auf 172.16.2.1 aufschlägt per SNAT über 5.230.x.x rausgeschickt. Der Openwrt Router weiß somit gar nichts von dieser IP. Nope da war ich auf dem Holzweg, du hast Recht Gliese, die IP Adresse wird tatsächlich über den GRE Tunnel geroutet. Dann funktioniert die Konfig so natürlich nicht.

 

[syhm]

Ich hab das ganze mal auf meiner pfsense getestet und es funktioniert mit Virtueller IP und entsprechender NAT/FW Regel. Speed und Latenz können sich sehen lassen:

Retrieving speedtest.net configuration...
Testing from GHOSTnet GmbH (5.230.x.x)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Schlueter Onlinedienste (Ruethen) [76.21 km]: 20.701 ms
Testing download speed................................................................................
Download: 738.82 Mbit/s
Testing upload speed......................................................................................................
Upload: 49.15 Mbit/s

Ich versuche das ganze jetzt für Openwrt abzubilden. Das GRE Interface sollte so konfiguriert werden und das dürfte dann erstmal passen. Jetzt fehlen Gateway, NAT und FW Regeln, dann sollte es auch über Openwrt klappen. Ich richte mir mal die Tage zum testen einen Openwrt Docker Container ein und dann könnte ich den Rest noch beisteuern. Vielleicht kriegst du es bis dahin schon so hin.

config interface 'noez1'
    option proto    'gre'
    option zone     'noez'
    option peeraddr '5.230.xxx.xxx'

config interface 'noez2'
    option proto    'static'
    option ifname   '@noez1'
    option ipaddr   '172.16.2.2'
    option netmask  '255.255.255.252'

config interface 'noez3'
    option proto    'static'
    option ifname   '@noez1'
    option ipaddr   '5.230.x.x'
    option netmask  '255.255.255.255'

 

[CoMo]

Bisher leider nicht. Dieses Fummel führt auch regelmäßig dazu, dass hier gar nichts mehr funktioniert.

Was mir aber auffällt: Der Tunnel scheint nach nem Reboot nicht sauber aufgebaut zu werden. Alle Pings schlagen fehl, es kommt nichts an.

Bis ich von Hand vom Router aus das interne Gateway 172.16.2.1 pinge. Dann kommen plötzlich auch die Pings auf die öffentliche Adresse durch (ohne Reply).

Mit der Firewall-Zone hatte ich bisher kein Glück.

 

[CoMo]

So. Ein Stück weiter bin ich gekommen. Wenn ich das Interface noez3 erstelle, als Alias von noez1 (der GRE-Tunnel) mit meiner öffentlichen Tunnel-IP als Adresse, und dann den Haken setze bei "Use default gateway", dann ist dieses Interface mein Default Gateway:

root@omnia:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.2.1      0.0.0.0         UG    0      0        0 gre4-noez1
5.230.205.34    62.156.244.13   255.255.255.255 UGH   0      0        0 pppoe-wan
10.111.111.0    0.0.0.0         255.255.255.0   U     0      0        0 tun_turris
62.156.244.13   0.0.0.0         255.255.255.255 UH    0      0        0 pppoe-wan
172.16.2.0      0.0.0.0         255.255.255.252 U     0      0        0 gre4-noez1
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 br-lan

Meine öffentliche Tunnel-IP kann ich dann pingen.

Leider kann ich dann nichts mehr im Internet erreichen:

root@omnia:~# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
 1  172.16.2.1 (172.16.2.1)  13.413 ms  13.344 ms  13.456 ms
 2  *  *  *
 3  *  *  *

An der Stelle habe ich manuell noch keine Routen gesetzt und auch an der Firewall nichts konfiguriert.

Nehme ich den Haken raus, habe ich wieder das Telekom Gateway als default Gateway:

root@omnia:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         62.156.244.12   0.0.0.0         UG    0      0        0 pppoe-wan
5.230.205.34    62.156.244.12   255.255.255.255 UGH   0      0        0 pppoe-wan
62.156.244.12   0.0.0.0         255.255.255.255 UH    0      0        0 pppoe-wan
172.16.2.0      0.0.0.0         255.255.255.252 U     0      0        0 gre4-noez1
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 br-lan

Dann kann ich aber wieder die öffentliche Tunnel-IP nicht pingen.

Festzuhalten ist: Die öffentliche Tunnel-IP am zweiten Alias-Interface zu konfigurieren, ist schon mal ein Schritt in die richtige Richtung 🙃

 

[syhm]

Festzuhalten ist: Die öffentliche Tunnel-IP am zweiten Alias-Interface zu konfigurieren, ist schon mal ein Schritt in die richtige Richtung 🙃

Sehr gut, fehlt nur noch die SNAT Regel dann dürfte auch ausgehender Traffic möglich sein.

config nat
        option target 'SNAT'
        option src 'noez2'
        option name 'SNAT noez'
        option snat_ip '5.230.x.x'

 

[CoMo]

Die SNAT Regel hab ich drin, das default Gateway habe ich noch nicht geändert. Möchte ich auch nicht, ich möchte ja nicht meinen kompletten Traffic über den Tunnel schicken.

Allerdings gibts bis hierhin schon ein Problem. Ich kann das Gateway von anderen Geräten im Netzwerk gar nicht erreichen.

Vom Router:

PING 172.16.2.1 (172.16.2.1) 56(84) bytes of data.
64 bytes from 172.16.2.1: icmp_seq=1 ttl=64 time=12.2 ms
64 bytes from 172.16.2.1: icmp_seq=2 ttl=64 time=12.6 ms

Von einem anderen Gerät:

PING 172.16.2.1 (172.16.2.1) 56(84) bytes of data.
From 192.168.100.1 icmp_seq=1 Destination Port Unreachable
From 192.168.100.1 icmp_seq=2 Destination Port Unreachable

Hier muss also noch eine Route oder sowas fehlen?

 

[Gliese]

Die Meldung "Destination Port Unreachable" kommt typischerweise, wenn eine Reject-Rule einer Firewall greift.
Daher prüfe das mal.