Routingfehler aufs Speedtouch?

[freerider]

Servus!

Ich komme einfach nicht von den Clients aufs Speedtouch 510 Modem drauf.
Routingtabelle vom Speedtouch:

Code: Alles auswählen

=>ip rtlist
        Destination Label                  Gateway       Intf Mtrc Status
255.255.255.255/32                     10.0.0.138       eth0   0  UP
      10.0.0.138/32                     10.0.0.138       eth0   0  UP
       127.0.0.1/32                      127.0.0.1       loop   0  UP
        10.0.0.0/24                     10.0.0.138       eth0   0  UP
     192.168.0.0/24                     10.0.0.140       eth0   0  UP
       224.0.0.0/4                      10.0.0.138*      eth0   0  UP
         0.0.0.0/0                      10.0.0.138*      eth0  70  UP


Die Firewall am Router blockt nichts. Wenn ich mich mit ssh auf den Router verbinde, lässt sich das Modem pingen und auch über telnet erreichen.



könnt ihr mir vielleicht weiterhelfen?
mfg, freerider

[Herculess]

du musst das 192.168.1.x/24 netz am speedtouch an deinen router weiterleiten

greets

[zid]

sehr schöne zeichnung
du hast dich anscheinend bei den routen vertippt. am st steht
192.168.0.0/24 10.0.0.140 eth0 0 UP
in deiner zeichnung hat das lan hinter dem router die id 192.168.1.0/24

>"...Wenn ich mich mit ssh auf den Router verbinde, lässt sich das Modem pingen und auch über telnet erreichen..."
das ist klar. die pakete vom router haben ja eine src-ip 10.0.0.x (hoffentlich gilt x = 140).

btw. der pptp- tunnel geht vom router bis zum 510er, der ppp-link geht vom router bis zum isp.

lg
zid

[freerider]

vielen dank Herculess und zid!
ich muss mich entschuldigen, die zeichnung ist nicht von mir, sondern aus dem internet, ich hab sie nur schnell adaptiert zur besseren darstellung meines problems. dabei dürfte ich wohl übersehen haben das mein netz hinter dem router das 192.168.0.x ist

vielleicht hier nochmal besser dargestellt:

Code: Alles auswählen

LAN  <---------------> LAN <-------Router-------> WAN <---------------> Speedtouch
192.168.0.0/24         192.168.0.200/24           10.0.0.140/24         10.0.0.138/24


[zid]

hm, dann ist das routing am st eh ok und die sache sollte laufen, mach ich auch immer so bei su.
wenns noch immer nicht geht, könntest du folgendes anschauen:

- die firewall am st. du hast offensichtlich am st eine r4.2 oder tiefer. da ist die firewall nicht stateful.
was ist der output von:
=>firewall list
=>firewall rule list

- welchen router hast du? bei manchen routern (z.b. linksys wrt160n, wrt54gl mit dd-wrt v24-sp1) gibts zoff mit den routen.

- das routing am client selbst, passiert mir sehr oft.
wenn du mehrere ips am client hast, wie ich hier jetzt z.b.
>ip a
...
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:4c:cd:aa:5c brd ff:ff:ff:ff:ff:ff
inet 10.0.1.146/24 brd 10.0.1.255 scope global eth0
inet 192.168.0.146/24 brd 192.168.0.255 scope global eth0
inet 10.0.0.146/24 brd 10.0.0.255 scope global eth0
...
mit diesen adressen komm ich mit meinem pc nie aufs st, weil der pc die 10.0.0.138 im anliegenden segment suchen würde...

[freerider]

servus zid!

=>firewall list
=>firewall rule list

folgendes kommt dabei raus

Code: Alles auswählen

=>firewall list
:firewall assign hook=input chain=None
:firewall assign hook=sink chain=sink
:firewall assign hook=forward chain=forward
:firewall assign hook=source chain=source
:firewall assign hook=output chain=None
=>
=>firewall rule list
:firewall rule create chain=forward index=0 srcintfgrp=wan dstintfgrp=wan action=drop
:firewall rule create chain=sink index=0 srcintfgrp=!wan action=accept
:firewall rule create chain=sink index=1 prot=icmp icmptype=echo-reply action=accept
:firewall rule create chain=sink index=2 prot=icmp icmptype=destination-unreachable action=accept
:firewall rule create chain=sink index=3 prot=icmp icmptype=time-exceeded action=accept
:firewall rule create chain=sink index=4 prot=udp dstport=dns action=accept
:firewall rule create chain=sink index=5 prot=udp dstport=bootpc action=accept
:firewall rule create chain=sink index=6 prot=udp dstport=snmp log=yes action=count
:firewall rule create chain=sink index=7 action=drop
:firewall rule create chain=source index=0 dstintfgrp=!wan action=accept
:firewall rule create chain=source index=1 prot=icmp icmptype=echo-request action=accept
:firewall rule create chain=source index=2 prot=udp dstport=dns action=accept
:firewall rule create chain=source index=3 prot=udp dstport=bootps action=accept

:firewall rule create chain=source index=4 prot=udp dstport=syslog log=yes action=count
:firewall rule create chain=source index=5 prot=udp dstport=snmptrap log=yes action=count
:firewall rule create chain=source index=6 prot=udp srcport=snmp log=yes action=count
:firewall rule create chain=source index=7 action=drop
=>Connection closed by foreign host.
#


router ist pfsense


sry für meine späte antwort

[zid]

hm, firewall rules sind eh die default rules. pfsense läßt den syn zum st auch durch.
du wirst am st nachschauen müssen, was mit dem syn und syn-ack passiert. ist etwas lästig, weil du dauernd umstecken mußt.
einen rechner ans st anschließen und folgende logging rules setzen:

Code: Alles auswählen

=>firewall rule create chain=sink index=0 prot=tcp syn=yes dstport=80 log=yes action=count
=>firewall chain create chain out
=>firewall rule create chain=out prot=tcp syn=yes ack=yes srcport=80 log=yes action=count
=>firewall assign chain out hook output

wenn du dann mit dem rechner 192.168.0.8 verbindest, erzeugt ein syn am st ca. folgenden log-eintrag:

Code: Alles auswählen

FIREWALL Hook: sink Rule Id: 0 Protocol: TCP Src_ip_port: 192.168.0.8:hi-port Dst_ip_port: 10.0.0.138:80 Action: count

der syn-ack:

FIREWALL Hook: output Rule Id: 0 Protocol: TCP Src_ip_port: 10.0.0.138:80 Dst_ip_port: 192.168.0.8:hi-port Action: count

lg
zid