Openwrt mit Telekom Austria PPTP

[mike85]

Conf2.PNG (29.3 KiB) 29717-mal betrachtet

So sieht die aktuelle Konfiguration aus. Was ich ultimativ erreichen will ist ein geroutetes openvpn. Die oben konfigurierte
Seite ist der Client.

Ich habe ein neues device angelegt:
vpn, unmanged, phys device tun0, firewall zone vpn
vpn, accept, accept, accept, allow forward from lan/to lan

Und die lan -> wan/vpn forward hab ich auch accept geschaltet. Weil ich sonst weder das st pingen kann noch einen vpn client pingen können sollte. Bitte lass das jetzt richtig sein

[zid]

also ich packs net...*kopfkratz*

hallo mike,

ich wollte den primitivansatz von früher mit der zone based firewall (ich nenn das ding ab jetzt "zbfw") so weit wie möglich imitieren und bin dabei auf was lustiges gestoßen: der openwrt router weigert sich am ppp-link zu maskieren.
so ein lauser...

genaugenommen hab ich im klicki-bunti das gesetzt:

openwrt1209_zbfw_comment1.png (135.63 KiB) 29634-mal betrachtet

mit diesem setup sieht die POSTROUTING chain voll ok aus...:

Code: Alles auswählen

# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 10 packets, 606 bytes)
pkts bytes target     prot opt in     out     source               destination
   17  1122 postrouting_rule  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    8   490 zone_lan_nat  all  --  *      br-lan  0.0.0.0/0            0.0.0.0/0
    3   164 zone_lan_st_nat  all  --  *      eth0.2  0.0.0.0/0            0.0.0.0/0
    6   468 zone_wan_nat  all  --  *      pptp-A1  0.0.0.0/0            0.0.0.0/0

# iptables -t nat -nvL postrouting_rule
Chain postrouting_rule (1 references)
pkts bytes target     prot opt in     out     source               destination

# iptables -t nat -nvL zone_lan_nat
Chain zone_lan_nat (1 references)
pkts bytes target     prot opt in     out     source               destination

# iptables -t nat -nvL zone_lan_st_nat
Chain zone_lan_st_nat (1 references)
pkts bytes target     prot opt in     out     source               destination

# iptables -t nat -nvL zone_wan_nat
Chain zone_wan_nat (1 references)
pkts bytes target     prot opt in     out     source               destination
    6   468 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0

...ich komm aber aus dem lan (rechner-ip: 192.168.1.146/24) nicht ins inet:

Code: Alles auswählen

>ping -c 4  8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

und wenn man am modem (bei mir aktuell ein tg585v7) mit einem kontrollrechner mitsnifft, dann sieht man, daß die pings eben unmaskiert rausgehen:

openwrt1209_zbfw_ping_no_masq.png (24.14 KiB) 29634-mal betrachtet

es kommt aber noch lustiger:
wenn man jetzt völlig unnötigerweise (die lan zone hat ja bereits fürs forwarding eine accept policy) nur das inter-zone forwarding lan -> wan explizit setzt (der rest bleibt gleich), konkret also das macht:

openwrt1209_zbfw_lan_wan_forw.png (19.61 KiB) 29634-mal betrachtet

dann ändert sich zwar in der POSTROUTING chain genau nix...:

Code: Alles auswählen

# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 2 packets, 116 bytes)
pkts bytes target     prot opt in     out     source               destination
    4   248 postrouting_rule  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 zone_lan_nat  all  --  *      br-lan  0.0.0.0/0            0.0.0.0/0
    3   164 zone_lan_st_nat  all  --  *      eth0.2  0.0.0.0/0            0.0.0.0/0
    1    84 zone_wan_nat  all  --  *      pptp-A1  0.0.0.0/0            0.0.0.0/0

# iptables -t nat -nvL postrouting_rule
Chain postrouting_rule (1 references)
pkts bytes target     prot opt in     out     source               destination

# iptables -t nat -nvL zone_lan_nat
Chain zone_lan_nat (1 references)
pkts bytes target     prot opt in     out     source               destination

# iptables -t nat -nvL zone_lan_st_nat
Chain zone_lan_st_nat (1 references)
pkts bytes target     prot opt in     out     source               destination

# iptables -t nat -nvL zone_wan_nat
Chain zone_wan_nat (1 references)
pkts bytes target     prot opt in     out     source               destination
    1    84 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0

...aber das masquerading funkt auf einmal, und die pings gehen sauber durch, s.a. bunti im nächsten post.
wir halten somit fest:
ab sofort wird das maquerading/nat nicht mehr in den nat tables, sondern in den filter tables aktiviert...
spaß beiseite- hast du vielleicht eine idee, was da abgeht?

lg
zid

[zid]

die traces von den durchgehenden pferden...

openwrt1209_zbfw_ping_masq.png (53.76 KiB) 29633-mal betrachtet

lg
zid

[mike85]

spaß beiseite- hast du vielleicht eine idee, was da abgeht?

Hmm nicht viel, außer das per default das interzone forwarding lan -> wan gesetzt ist. Siehe:

Conf Chello.PNG (26.26 KiB) 29619-mal betrachtet

Beim weiteren testen musste ich festellen das für den vpn traffic vpn > lan accept,accept,reject reicht.
Wenn ich mich vom lan aus mit dem browser aufs modem connecten will muss ich forward auch noch auf accept stellen.

[zid]

>"...außer das per default das interzone forwarding lan -> wan gesetzt ist. Siehe:..."
ja, nur in deinem bunti ist die policy fürs forwarding der lan zone auf reject gesetzt, und da mußt du die policy mit einer inter-zone rule lan -> wan overrulen, weil sonst die pakete gar nicht rausgehen, unabhängig davon, ob jetzt maskiert wird oder nicht.
bei mir hingegen steht die zone policy vom lan auf accept, und pakete gehen ja auch ins wan (s. bunti openwrt1209_zbfw_ping_no_masq.png, die trace wird am *tg* gezogen, die pings haben den tp-link bereits verlassen), nur werden sie halt nicht maskiert. und um das masquerading zu aktivieren, muß ich eben eine zusätzliche und überflüssige accept rule (genaugenommen is es auch eine subchain "zone_wan_ACCEPT") in der subchain zone_lan_forward (die sitzt in der filter! table) setzen...

lg
zid

[zid]

aja...
>"...Wenn ich mich vom lan aus mit dem browser aufs modem connecten will muss ich forward auch noch auf accept stellen..."
das is klar.
du weißt aber eh, daß openwrt einen telnet- und ssh-client hat. du kannst auch mit dem telnet-client aufs st gehen. das nervige is halt, daß man zuerst auf die shell des router gehen muß, um dann von dort aus den telnet-client anzuwerfen. doppelt gemoppelt...

lg
zid

[mike85]

ja, nur in deinem bunti ist die policy fürs forwarding der lan zone auf reject gesetzt, und da mußt du die policy mit einer inter-zone rule lan -> wan overrulen, weil sonst die pakete gar nicht rausgehen, unabhängig davon, ob jetzt maskiert wird oder nicht.
bei mir hingegen steht die zone policy vom lan auf accept, und pakete gehen ja auch ins wan (s. bunti openwrt1209_zbfw_ping_no_masq.png, die trace wird am *tg* gezogen, die pings haben den tp-link bereits verlassen), nur werden sie halt nicht maskiert. und um das masquerading zu aktivieren, muß ich eben eine zusätzliche und überflüssige accept rule (genaugenommen is es auch eine subchain "zone_wan_ACCEPT") in der subchain zone_lan_forward (die sitzt in der filter! table) setzen...

Ich verstehe auf was du hinaus willst. Ich habe mich darüber auch schon gewundert, aber für mich ist da sovieles neu, da komme ich aus dem wundern gar nicht mehr raus
Theoretisch müsste es sich ja ja mit meiner vpn rule ein paar Screenshots vorher gleich verhalten. Wobei ich es nie ohne inter-zone forwards probiert habe und die forward immer auf reject hatte.

das is klar.
du weißt aber eh, daß openwrt einen telnet- und ssh-client hat. du kannst auch mit dem telnet-client aufs st gehen. das nervige is halt, daß man zuerst auf die shell des router gehen muß, um dann von dort aus den telnet-client anzuwerfen. doppelt gemoppelt...

Jop. Früher (TM) hab ich immer ssh port forwardings genommen local 9999 > remote 10.0.0.138:80. Das hat auch immer prima geklappt.

Was sagst du zu meiner vpn -> lan rule ?

[Velociraptor]

In der neuen Version von OpenWRT 15.05 wird zusätzlich noch das Paket kmod-nf-nathelper-extra benötigt wie nach langer suche hier gefunden https://dev.openwrt.org/ticket/19370

[mike85]

In der neuen Version von OpenWRT 15.05 wird zusätzlich noch das Paket kmod-nf-nathelper-extra benötigt wie nach langer suche hier gefunden https://dev.openwrt.org/ticket/19370

Interessant, ich habe beim ersten Upgrade auch die Fehler aus dem trac im syslog gehabt, hab dann am selben Abend nochmal von vorne angefangen und hatte dann mit der Installation Erfolg.

Die Pakete habe ich auch alle drauf, wurde automatisch aufgelöst durch die Installation von luci-proto-ppp.