Openwrt mit Telekom Austria PPTP

[mike85]

Hallo, hat jemand von euch sowas am laufen ? Ich bin nach folgenden Anleitungen ohne Erfolg vorgegangen.

https://forum.openwrt.org/viewtopic.php?id=36260
http://www.gernot-walzl.at/Miscellaneou ... ia.de.html

Ich hab leider keinen Anhaltspunkt woran es scheitern könnten da im logread nichts von den pppd connect versuchen auftaucht. Das einzige was ich sehen kannst ist dass das pptp Interface immer hoch- und runterfährt.

TP Link WDR3600 mit 12.09 Altitude Adjustment

[jutta]

läuft dein internetzugang überhaupt mit pptp? welches modem hast du? und deine router-einstellungen wären sinnvoll, um eventuelle fehler zu finden.

zu deiner ersten frage: ja, viele. https://www.google.at/search?q=openwrt+ ... e-AT&gbv=1

[zid]

>"...Das einzige was ich sehen kannst ist dass das pptp Interface immer hoch- und runterfährt..."
was sagen die logs genau? wie weit kommst du bei der einwahl?
grundsätzlich funkt das pptp bei der 12.09er praktisch ootb.

- das paket ppp-mod-pptp installieren

Code: Alles auswählen

# opkg update
# opkg install ppp-mod-pptp

- auf eth0.2 eine statische ip 10.0.0.x/24 setzen (mit x != 138). das soll ca. so aussehen:

Code: Alles auswählen

# uci show network.wan
network.wan=interface
network.wan.ifname=eth0.2
network.wan.proto=static
network.wan.netmask=255.255.255.0
network.wan.send_rs=0
network.wan.ipaddr=10.0.0.129

- pptp-dialer auf eth0.2 setzen...:

Code: Alles auswählen

# uci show network.A1
network.A1=interface
network.A1.proto=pptp
network.A1.server=10.0.0.138
network.A1.username=<deine-user-id>
network.A1.password=<dein-pw>
network.A1.mtu=1460

...und in /etc/ppp/options.pptp mppe deaktivieren, weil sonst die auth nicht haut. die options.pptp soll danach so aussehen:

Code: Alles auswählen

# cat /etc/ppp/options.pptp
noipdefault
noauth
nobsdcomp
nodeflate
idle 0
# no encryption
# mppe required,no40,no56,stateless
maxfail 0

- danach nur noch das masquerading für die wan zone/den ppp-link (in diesem beispiel "A1") anpassen:

Code: Alles auswählen

# uci set firewall.@zone[1].network=A1
# uci set firewall.@zone[1].masq=1
# uci get firewall.@zone[1].network
A1
# uci get firewall.@zone[1].masq
1

- router rebooten

- nach dem reboot sollte der ppp-link aktiv sein, die routen so aussehen...:

Code: Alles auswählen

# ip r
default via <ip-ppp-peer> dev pptp-A1  proto static
10.0.0.0/24 dev eth0.2  proto kernel  scope link  src 10.0.0.129
10.0.0.138 dev eth0.2  proto static  scope link
<ip-ppp-peer> dev pptp-A1  proto kernel  scope link  src <local-ppp-ip>
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1

- ...und das masquerading so:

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
  250 17651 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
  247 17487 zone_wan_nat  all  --  *      pptp-A1  0.0.0.0/0            0.0.0.0/0

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

lg
zid

[mike85]

läuft dein internetzugang überhaupt mit pptp? welches modem hast du?

Speedtouch 510

was sagen die logs genau? wie weit kommst du bei der einwahl?

Nix. Ich nix von ppp connects drinnen. Ich hab mal ein bisschen im openwrt forum gestöbert und dort
wird behauptet das man ein dump debug an die options.pptp anhängen soll um sachen im logread zu sehen.
Das hab ich allerdings zu spät gelesen.

https://forum.openwrt.org/viewtopic.php ... 18#p211218

Die Settings von options.pptp hatte ich natürlich nicht so wie von dir beschrieben. Gut Möglich das
deswegen der link nicht hochkam. Ich kann leider erst in ein paar Tagen wir testen. Gebe dann aber rückmeldung.

- pptp-dialer auf eth0.2 setzen...:

Wo/wie setzte ich das ?

[zid]

st510...! woow, eecht geil!

hallo mike,

>"...Wo/wie setzte ich das ?..."
ich spiel das ganze mal mim klicki-bunti durch:

1. du installierst das paket ppp-mod-pptp:
details s. mein letzter post.

2. du konfigurierst den ipoe-link (=eth0.2), sodaß eine verbindung zum pptp-server (=st510) aufgebaut werden kann:
im webgui nach Network > Interfaces > wan > Edit gehen und die netparms wie hier setzen (ip darf nicht 10.0.0.138 sein):

openwrt1209_eth0.2_conf.png (58.57 KiB) 47182-mal betrachtet

kein gate setzen, weil du sonst beim pppd die ppp-option "replacedefaultroute" setzen mußt. unnötige mehrarbeit...

3. firewall für eth0.2 konfigurieren:
wir legen den eth0.2 in eine neue zone, die ich lan_st nenne.
du gehst nach Network > Firewall > General Settings und klickst "WAN" auf "Edit" und nimmst bei den "Covered Networks" das "wan" raus:

openwrt1209_fire_modify_wan.png (61.88 KiB) 47182-mal betrachtet

mit "Save & Apply" bestätigen. danach gehst du wieder nach Network > Firewall > Gerneral Settings, klickst auf "Add" und definierst/konfigurierst die neue zone lan_st mit folgenden einstellungen:

openwrt1209_fire_lan_st_config.png (58.95 KiB) 47182-mal betrachtet

fortsetzung im nächsten post...

lg
zid

[zid]

...fortsetzung:

danach wieder mit "Save & Apply" bestätigen. das ganze soll dann so aussehen:

openwrt1209_fire_lan_st_config_final.png (51.41 KiB) 47180-mal betrachtet

4. pptp-dialer auf eth0.2 konfigurieren:
du gehst nach Network > Interces, klickst auf "Add new interface..." und nimmst folgende einstellungen vor:openwrt1209_pptp-dialer definition.png

openwrt1209_pptp-dialer_definition.png (19.45 KiB) 47180-mal betrachtet

mit "Submit" bestätigen und dann die einwahlparms setzen:

openwrt1209_pptp-dialer_config.png (40.92 KiB) 47180-mal betrachtet

fortsetzung im nächsten post...

lg
zid

[zid]

...fortsetzung:

mit "Save & Apply" konfig abschließen und bei den "Advanced Settings" mtu reduzieren auf 1460:

openwrt1209_pptp-dialer_set_mtu.png (57.59 KiB) 47178-mal betrachtet

danach wieder "Save & Apply".

5. firewall - der dialer kommt in die wan-zone, und das lan wird maskiert:
du gehst wieder nach Network > Firewall, klickst bei "wan" auf "Edit" und dann:

openwrt1209_fire_pptp-dialer_config.png (58.83 KiB) 47178-mal betrachtet

nach der bestätigung mit "Save & Apply" soll das ganze so aussehen:

openwrt1209_fire_final.png (47.85 KiB) 47178-mal betrachtet

6. mppe in /etc/ppp/options.pptp deaktivieren wie früher beschrieben

router rebooten, und das war schon alles...

lg
zid

[mike85]

st510...! woow, eecht geil!

Ich wollte/will eigentlich eh schon länger auf Gigaspeed upgraden da ich aber bis jetzt immer "Stess" hatte, hab
ich es mir bis jetzt einfach gespart. Mit Gigaspeed gibts dann aber pppoe oder ?

Ok, mit dialer ist die konfig der wan Schnitstelle gemeint. Das hätte ich sogar selber geschafft
Aber den Zonen Kram vermutlich nicht oder nur nach langem basteln. Jedenfalls thx im voraus! Werde das asap
umsetzten und dann nochmal rückmelden.

[zid]

>"...Mit Gigaspeed gibts dann aber pppoe oder ?..."
die ta realisiert gs16 mit adsl2+ und vdsl2, gs30 kann nur mit vdsl2 realisiert werden.
adsl(2+) rennt mit pptp, vdsl2 rennt mit pppoe. auf alle fälle kannst du dir dein schönes 510er beim umstieg auf gs abschminken, weil das ding nur adsl, aber kein adsl2+ kann.

>"...Aber den Zonen Kram vermutlich nicht oder nur nach langem basteln..."
naja, der zonenkram is auch so ein ding...

1. ein paar allgemeine bemerkungen zum zonenkram
wenn du heutzutage mit den mädels und jungs aus dem sicherheitsbereich über firewalls redest, dann mußt du in zonen reden und denken. tust du das nicht, dann wirst du sowieso für grenzdebil gehalten. du wirst mich jetzt natürlich fragen, warum diese leute so geil auf zonenbasierte konzepte sind.
antwort: das zauberwort lautet "skalierbarkeit".
und die sog. "skalierbarkeit" schaut ca. so aus:
- du definierst zuerst und hoffentlich clever verschiedene (security) zones.
- du charakterisiert den den traffic, mit dem dus zu tun hast.
- du legst traffic policies für den charakterisierten traffic zwischen den verschiedenen zones fest. und jetzt kommts- tata-tata:
- du ordnest die verschieden schnittstellen den zones zu. und da heutzutage jeder durchschnittsuser mindestens 10 oder 20 inetzugänge sowie ebenso viele lans hat- und dann kommen natürlich auch tagtäglich neue hinzu- greift dieses system bestens.
du hast eine neue schnittstelle?
nullo problemo- die neue schnittstelle wird einer zone zugeordnet und schon fertig. die firewallkonfig per se muß nicht angetastet werden, weil die zones samt policies eh schon vordefiniert sind. skalierbarkeit vom feinsten...
dieses konzept hat natürlich seinen preis. mach mal...:

Code: Alles auswählen

# iptables -nvL
# iptables -t nat -nvL
# iptables -t mangle -nvL

...und zähl nur alle (sub)chains, keine rules!, ab. da bist echt a zeiterl beschäftigt, der eine oder andre weiße spritzer aufm schreibtisch zur aufrechterhaltung des elektrolythaushalts is in dem fall durchaus angebracht...
und das ganze wird noch lustiger, wenn man bedenkt, daß man bei einem netzwerk mit 1x wan + 1x lan *genattet* und ohne weiterleitungen mit 2 rules auskommen kann.

2. ein paar konkretere bemerkungen zum zonenkram in deiner situation
du wirst mich jetzt natürlich wieder fragen, warum ich so bescheuert bin und den eth0.2 in eine eigene zone lege, die ganze frewall is mit dem zonekram eh schon ziemlich wild...

- die kurze antwort: es geht um den zugriff aufs st, und ich kann masquerading nicht ausstehen.

- die etwas länglichere antwort:
ich kann logs mit relativen zeitstempeln auch nicht ausstehen und muß deshalb am st/tg für den ntp-client eine default route via openwrt router setzen. schaut so aus:

Code: Alles auswählen

=>ip rtlist
Label          Destination          Gateway  Interface     Mtc Admin  Oper
              10.0.0.138/32       127.0.0.1  loop          0   UP     [UP]
              10.0.0.255/32       127.0.0.1  loop          0   UP     [UP]
               127.0.0.1/32       127.0.0.1  loop          0   UP     [UP]
         255.255.255.255/32       127.0.0.1  loop          0   UP     [UP]
                10.0.0.0/24      10.0.0.138  LocalNetwork  0   UP     [UP]
                 0.0.0.0/0       10.0.0.129  LocalNetwork  1   UP     [UP]
=>

so, die default route is also eh schon da, und dann seh ichs net wirklich ein, am eth0.2 *völlig unnötig* zu maskieren, was passieren würde, wenn ich den eth0.2 in die wan zone legte, weil dort zwangsläufig maskiert werden muß. ergo eigene zone ohne masquerading für den eth0.2. und ich kann dennoch aus dem lan des openwrt router aufs st/tg zugreifen, weil dort sowieso die default route schon steht...

lg
zid

[mike85]

die ta realisiert gs16 mit adsl2+ und vdsl2, gs30 kann nur mit vdsl2 realisiert werden.
adsl(2+) rennt mit pptp, vdsl2 rennt mit pppoe. auf alle fälle kannst du dir dein schönes 510er beim umstieg auf gs abschminken, weil das ding nur adsl, aber kein adsl2+ kann.

Bei mir wäre eh nur gigaspeed 16 verfügbar.

Ich denke mal das ich deine Erklärung verstanden habe. Was mir im vergleich zu einer chello firewall konfiguration auffällt ist dass das wan interface forwards zulässt. Ich nehme an da es ohne nicht funktionieren würde ?
Theoretisch müsste ich ohne zusätzliche Zone auskommen, würde dann allerdings nicht aufs modem kommen und müsste forward auf accept ändern ?

[mike85]

Als Bonus Verständnis Frage zu Zonen, wie würde ich diese Regel abbilden [1]:

Accept, Accept, Accept, Coverd Networks Lan, allow forward to/from lan ?

[1]: http://wiki.openwrt.org/doc/howto/vpn.s ... r.firewall

[mike85]

Ich denke mal das ich deine Erklärung verstanden habe. Was mir im vergleich zu einer chello firewall konfiguration auffällt ist dass das wan interface forwards zulässt. Ich nehme an da es ohne nicht funktionieren würde ?
Theoretisch müsste ich ohne zusätzliche Zone auskommen, würde dann allerdings nicht aufs modem kommen und müsste forward auf accept ändern ?

Mit nicht funktionieren meine ich den aufbau der ppp session, oder dient das forward dazu um von einem privaten netz in das andere zu kommen ? Also von z.b. 192.168.1.0/24 -> 10.0.0.0/24 ?

[zid]

>"...Mit nicht funktionieren meine ich den aufbau der ppp session, oder dient das forward dazu um von einem privaten netz in das andere zu kommen ? Also von z.b. 192.168.1.0/24 -> 10.0.0.0/24 ?..."
netfilter/iptables (das ist die firewall von openwrt, uci ist nur ein frontend für netfilter) besteht grundsätzlich aus 3 main filter chains:
INPUT, OUTPUT und FORWARD

- INPUT, OUTPUT und alle subchains dieser 2 main chains
sind für den local/self traffic zuständig. das ist also der traffic der zum router selbst geht(= INPUT) oder vom router kommt (= OUTPUT).

- FORWARD und alle subchains dieser main chain
sind für den transit traffic, also jenen traffic zuständig, der bei einer schnittstelle des router reinkommt und bei einer andren wieder rausgeht.

- bei einem genatteten zugang kann man die policy der FORWARD auf ACCEPT stellen und die chain selbst leer lassen, weil sie inbound nicht zum zug kommt.
das hängt mit der reihenfolge der paketverarbeitung zusammen. die reihefolge der verarbeitung ist das wichtigste bei einem router, kennst du sie nicht, kannst du brausen gehen, weil dann die firewallkonfig zum glückspiel wird.
bei netfilter sieht die paketverarbeitung für ein neues paket, das aus dem wan reinkommt, so aus:

1. das paket kommt mit dest-ip = deine öffentliche ip rein und durchläuft zuerst die PREROUTING chain der der nat table (die nat table ist keine filter table, sonder eine eigene tabelle, die eben fürs nat zuständig ist).

2. die nat table ist, wenn keine weiterleitungen vorhanden sind, leer und hat die policy ACCEPT drauf. die dest-ip wird also nicht verändert und es kommt

3. zur routing entscheidung. der router stellt fest, daß die dest-ip gleich deiner öffentlichen ip ist, das paket ist also self traffic und wird

4. in richtung INPUT chain geschickt. die INPUT chain hat die policy DROP drauf und 1,2 ACCEPT rules für den traffic aus dem lan (sonst würdest du nicht auf den router kommen, um ihn zu konfigurieren), aber kein ACCEPT fürs in-interface = wan. es greift also die policy und das paket wird still verworfen. die FORWARD chains wird von dem ganzen prozeß überhaupt nicht tangiert und kann deshalb offen bleiben.

5. was passiert jetzt wenn du jetzt eine weiterleitung in der preroutng chain einrichtest, beispielhaft jetzt angenommen, du hast einen webserver (tcp/80) mit der ip 192.168.1.254 im lan rumstehen. das syn-packerl kommt mit dest-ip = deine öffentliche ip und dest-port = tcp/80 rein, durchläuft wieder die prerouting chain und trifft dort auf deine dnat rule. folge: die öffentliche dest-ip wird übersetzt auf die private ip 192.168.1.254. es kommt danach wieder zur routing entscheidung, und der router stellt fest:"oops, das is transit traffic, also ab damit in die FORWARD chain...". die FORWARD chain is leer und hat die policy ACCEPT. das paket kann also ohne weiters- und vor allem ohne zusätzliche, selektive ACCEPT rules- durch und kommt beim server an.

unterm strich wird bei *genatteten* zugängen alles über die prerouting chain gesteuert. bei gerouteten zugängen verhält sich die gschicht schon ganz anders, da würd ich die FORWARD chain nicht offen lassen...

lg
zid

[zid]

ein kleines beispiel als nachtrag.
du könntest testweise mal folgendes versuchen:

1. du benennst die /etc/config/firewall auf /etc/config/firewall.orig um und erzeugst eine neue firewall config namens /etc/config/firewall.local, die nur den include abschnitt der orig enthält:

Code: Alles auswählen

# mv /etc/config/firewall /etc/config/firewall.orig
# cat << EOF >> /etc/config/firewall.local
> config include
>         option path '/etc/firewall.user'
> EOF

kurze kontrolle:
# cat /etc/config/firewall.local
config include
        option path '/etc/firewall.user'

2. du benennst die /etc/firewall.user auf /etc/firewall.user.orig um und erzeugst eine neue user config namens /etc/firewall.user.local, die so aussieht:

Code: Alles auswählen

# mv /etc/firewall.user /etc/firewall.user.orig
# cat << EOF >> /etc/firewall.user.local
> #
> # flush all chains first
> iptables -F
> iptables -X
> #
> # set the policies of the main chains
> iptables -P INPUT DROP
> iptables -P FORWARD ACCEPT
> iptables -P OUTPUT ACCEPT
> #
> # accept local traffic from inside
> iptables -A INPUT -i eth0.2 -j ACCEPT
> iptables -A INPUT -i br-lan -j ACCEPT
> #
> # masquerading on pptp-A1
> iptables -t nat -A POSTROUTING -o pptp-A1 -j MASQUERADE
> EOF

wieder kontrolle:
# cat /etc/firewall.user.local
#
# flush all chains first
iptables -F
iptables -X
#
# set the policies of the main chains
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
#
# accept local traffic from inside
iptables -A INPUT -i eth0.2 -j ACCEPT
iptables -A INPUT -i br-lan -j ACCEPT
#
# masquerading on pptp-A1
iptables -t nat -A POSTROUTING -o pptp-A1 -j MASQUERADE

3. jetzt nur noch das graffl "scharf" machen. dazu werden 2 links mit den "kanonischen" namen /etc/config/firewall und /etc/firewall.user gesetzt, die auf die local configs verweisen (die dinger fungieren sozusagen als 'ne art zeiger).

Code: Alles auswählen

ln -s /etc/config/firewall.local /etc/config/firewall
ln -s /etc/firewall.user.local /etc/firewall.user

wieder kontrolle:
# ls -l /etc/config | grep firewall
lrwxrwxrwx    1 root     root            26 Oct 31 11:46 firewall -> /etc/config/firewall.local
-rw-r--r--    1 root     root            56 Oct 31 11:44 firewall.local
-rw-r--r--    1 root     root          2189 Oct 29 14:28 firewall.orig
# ls -l /etc/ | grep firewall
lrwxrwxrwx    1 root     root            24 Oct 31 14:55 firewall.user -> /etc/firewall.user.local
-rw-r--r--    1 root     root           364 Oct 31 14:46 firewall.user.local
-rw-r--r--    1 root     root           139 Oct 31 11:34 firewall.user.orig

4. router rebooten, und danach kannst du dir mit "iptables -nvL..." die regeln mal anschauen. du wirst unterschiede zum zone based konzept bemerken, obwohl die local firewall das gleiche leistet.

5. wenn du wieder zurückwillst, dann einfach die 2 "zeiger" löschen und neu setzen, sodaß sie auf die origs verweisen.
*vorsicht* beim linking/pointing. wenn du dich da vertust, bist du weg vom fenster und der failsafe mode is angesagt. ist grad unlängst einem freund passiert, ich bin fast weggebrochen vor lauter lachen.

lg
zid

[mike85]

Na das werde ich dann mal lieber in einer vm testen ln -s etc ist bekannt. Ich hab mich bis jetzt gegen netfilter/iptables gewehrt (erfolgreich wie man merkt).

Ein paar Dinge noch:
Bei mir sieht die config jetzt so aus:

conf.PNG (31.08 KiB) 46864-mal betrachtet

(Bei deinem Screenshot)

1.) Da ist kein Forwarding Lan -> Wan, damit sollte man von Lan ja nicht ins Internet kommen ?
2.) Ich muss bei der ersten zone Forward auf accept ändern damit ich das Modem pingen kann.
3.) Die dritte Zone sieht auch anders aus, das kommt allerdings automatisch wenn ich bei wan forward from wan_st anhake.

Online bin ich damit jedenfalls schon mal.