Router achter router werkt niet

[TommyboyNL]

Ik probeer nu op een klein kantoortje een netwerk op te zetten, maar dat wil niet echt lukken. Het kantoortje zit in een studentencomplex, waar een gateway hangt welke de internettoegang regelt. Daarachter hangt een switch, waarvandaan naar elke kamer een kabel loopt. In het netwerk kunnen alle machines elkaar dus zien. Als ik een switch aansluit op onze netwerkoutlet, dan kan ik gewoon meerdere PCs van internet voorzien.
Wij willen echter ook een paar netwerkprinters aansluiten, en het is niet wenselijk dat het hele complex hier kan printen, dus moet er een router tussen. Hier klemt de schoen. Zodra ik een router aansluit, en deze correct configureer (kabel uit muur in WAN poort, WAN Interface als DHCP ingesteld, etc.), gaat het fout. De router kan wel het internet op, maar alles dat achter de router hangt niet. De gateway van het complex filtert al het verkeer weg.
Ik heb al contact gehad met de netwerkbeheerder/internetprovider (Utelisys), en het is gewoon toegestaan om een router aan te sluiten. Zij hebben ook al meerdere dingen in hun gateway aangepast om te proberen of we dan wel internet hebben, maar dit mocht niet baten.
Routers die ik geprobeerd heb: Sitecom WL-341 V1 001, Linksys E1200. Als testmachines heb ik een Linux (Ubuntu 10.04), Windows 7 bak, en mijn android telefoon beschikbaar.
Ik weet het nu ook niet meer. Heeft iemand anders toevallig nog een brijlante ingeving?

[Verwijderd]

Zeker weten dat de gateway van het complex alles weg filtert?

[Marcks]

Als je de printers achter de NAT van de tweede router parkeert, kan buiten dat netwerk praktisch geen onderscheid worden gemaakt tussen verkeer dat van de router zelf afkomstig is en dat van hosts achter die router. Het is dan ook zeer waarschijnlijk dat de router van het complex de boel 'wegfiltert'. Ik vermoed dat de configuratie van het tweede netwerk zelf niet op orde is, maar daar valt op grond van deze informatie verder niet veel zinnigs over te zeggen.

[Fiber]

Ik denk dat je een managed switch nodig heb ipv een router. Of een printservertje dat de toegang tot je printers regelt. Geen router in ieder geval.

[Nextron]

Gebruik je achter de router hetzelfde IP-bereik dat je gebruikt zonder de router? Dat kan een probleem opleveren.

[TommyboyNL]

Als ik naar buiten probeer te pingen, krijg ik de volgende reactie:

code:

From 145.107.8.129.pap.surfnet.utelisys.net (145.107.8.129) icmp_seq=1 Packet filtered

145.107.8.129 is de gateway die het internetverkeer voor ons /25 blok regelt, onze gateway heeft als extern IP 145.107.8.239 , en als lokaal IP 192.168.1.1
Hieruit maak ik dus op dat het verkeer niet door mijn router weggefilterd wordt.

Alle machines draaien gewoon een DHCP client, en krijgen een IP adres uit het 192.168.1.0/24 subnet toegewezen.

[Gunner]

je hebt op de andere router DHCP uitgezet neem ik aan?

[TommyboyNL]

De complexrouter kan ik niet bij, en die doet gewoon DHCP. Onze eigen router (Momenteel dus de Linksys E1200) draait wel DHCP, omdat hij gewoon als gateway moet fungeren, niet als switch ofzo.

[Fairy]

Probeer intern sowieso een andere ip reeks in te stellen, dit kan problemen geven.

Zorg dat je pc's de router als default gateway hebben.

Een managed switch heb je niet nodig. Je wilt niets te maken hebben met die andere pc's in het netwerk, je wilt je eigen netwerk, dus sluit dat af via de WAN poort.

[TommyboyNL]

In ons kantoor draaien we al op een andere IP reeks dan de rest van het complex. Wij gebruiken 192.168.1.0/24, en het complex gebruikt 125.107.8.128/25.
De PCs hebben natuurlijk onze router als dafault gateway, DNS server, etc. Dat wordt gewoon door DHCP geregeld.

[RocketKoen]

Kun je op de printer niet instellen wie er toegang heeft? Lijkt me wel een standaard functie van een netwerk printer.

Een router achter een router is geen handige manier van netwerken.

[TommyboyNL]

Wellicht kan je op een printer instellen wie er mogen printen, maar we hebben nu al twee netwerkprinters staan, en straks komt daar wellicht ook een NAS bij. Ik wil niet continue op alle printers, NASsen, etc. bij moeten houden welke IP adressen er wel en niet bij mogen. Ik wil gewoon een eigen afgezonderd subnet hier hebben. Bovendien is de pool van 128 IP adressen voor het complex natuurlijk vrij snel leeg, helemaal als er hier 10 a 20 mensen zitten, welke met hun laptop en/of telefoon op het netwerk duiken.

Oh, en een router achter een router kan prima, heb ik vaak genoeg gedaan. Dit is gewoon noodzakelijk als je een eigen subnet wilt, zodat er geen onbevoegden op je netwerkje komen.

[ Voor 15% gewijzigd door TommyboyNL op 07-06-2012 16:34 ]

[Fiber]

Het kan ook wel, als je het echt wil, het is alleen even puzzelen met instellingen, ip-ranges, vaste ip's etc.

[Bierkameel]

Koop een Cisco SLM2008 of een andere switch met VLAN's, daar kan je dat soort dingen makkelijker mee regelen.

[TommyboyNL]

VLANs heb ik geen ervaring mee, maar wil ik me wel in verdiepen. Belangrijkste is gewoon dat iedereen hier zijn laptop in kan pluggen, en meteen internet heeft, en kan printen, zonder nog veel rare dingen op de laptop zelf in te moeten stellen voor de VLANs.

[Petervanakelyen]

Gooi je router eens in een andere range? Wat je ook eens kan proberen is het MAC-adres van je computer clonen op de WAN-poort van je router. Bij de Linksys E1200 staat die optie bij "Setup" -> "MAC Address Clone".

[TommyboyNL]

MAC adres klonen heb ik al eens geprobeerd. Helpt niet. Andere range heb ik ook al geprobeerd. Helpt ook niet.

[gerhardt7]

kijk of de ip adressen afzonderlijk van elkaar zijn.
zet dhcp op de router uit en zocht dat pc in de zelfde range zit als de binnenkant van het netwerk
probeer de router te pingen. als je de router kan pingen moet je de wan kant van de router pingen wil dit dan is het waarschijnlijk dns probeer eens op een gewoone computer anders 8.8.8.8 te pingen

[Petervanakelyen]

Maar hoe in hemelsnaam maakt de router in het complex een onderscheid tussen een normale client en een router als zelfs het mac-adres gelijk is? Blijkbaar staat voor die laatste namelijk packet filtering enabled, maar voor normale clients niet.

[ Voor 8% gewijzigd door Petervanakelyen op 07-06-2012 22:39 ]

[gerhardt7]

mac adres heeft hier niks mee te maken na mijn weten het is of het natten wat niet goed gaat of iets wat met dns of dhcp

[Nextron]

Heeft die router een soort van WAN-check of bijvoorbeeld tijdsynchronisatie via NTP? Dan kan je zien of de router zelf wel gebruik kan maken van de internetverbinding, of dat het routen fout gaat.

[gerhardt7]

zou zeggen werk eerst even af wat ik zij met ping na gateway router binnenkant kan dat dan na buiten
kan dat ook dan na de andere router als dit kan dan weet je dat het lukt maar maar soms moet je in de eerste route ook een routing en hier kun je ook een router op gegeven

[TommyboyNL]

Als ik mijn laptop direct aansluit op de muur, krijgt die gewoon een IP adres uit de 145.107.8.128/25 range toegewezen, en werkt internet prima.
Sluit ik de router aan op de muur, dan krijgt die (voor zijn WAN interface) een IP adres uit de 145.107.8.128/25 range. De router heeft dan ook een internetverbinding, hij kan gewoon pingen en traceroutes doen naar 8.8.8.8 . Mijn laptop die daarachter hangt, krijgt echter geen internetverbinding. Mijn laptop krijgt een IP uit de 192.168.1.0/24 reeks, en kan wel de router pingen, maar niet de 145.107.8.129 gateway, of 8.8.8.8 .
Of ik het WAN IP van de router kan pingen, weet ik niet, zal ik morgen even testen, ik ben nu niet op kantoor.
Dit gaat overigens over de Linksys E1200 router.

Is aan netwerkpakketjes te zien of ze van mijn router, of mijn laptop vandaan komen, desnoods door middel van DPI?

gerhardt7, ik vind het prettig dat je probeert te helpen, maar het lukt me niet om uit je berichtjes te distilleren wat je nou exact bedoelt. Wat leestekens en hoofdletters zouden je bericht een stuk beter leesbaar maken.

[gerhardt7]

sorry nederlands niet me sterkste vak. maar ik denk dat ik het begrijp. je kan de binnen kant van de router pingen. maar de buiten kant niet. dat houd in dat je je nating niet voor elkaar hebt. als dat het geval is

[Raymond P]

Volgens Google heeft je router een optie RIP. Check voor de zekerheid ff of deze uit staat.
Als er iets gefilterd wordt aan de andere kant zou dat zomaar kunnen doordat er een collision is door een ander privenetwerkje met dezelfde range ofzo.
Ook heeft ie de mogelijkheid tot static routing, ook niet handmatig aan zitten.

Vergeet het pingen, gewoon gelijk een stap verder.
Pak het gateway adres dat je router krijgt van de andere router.

En doe een traceroute naar dat ip.
Windows:
tracert -d <ip gateway>
Linux:
traceroute -n <ip gateway>

Geef die informatie eens terug.

Als het kan, doe gelijk hetzelfde met 8.8.8.8 of een ander extern ip.

Edit: doe dit vanaf je laptop achter je eigen router, het liefst via een kabeltje.
nogmeeredit: Ik zie nu pas dat je niet bij de hardware bent.
Als je morgen ervoor staat, geef je router dan eens een reset naar factory settings.

[ Voor 15% gewijzigd door Raymond P op 07-06-2012 23:17 ]

[Verwijderd]

Beste,

Stel je subnetmasker eens wat ruimer in... 255.0.0.0 ipv 255.255.255.0. (op je dhcp op het private net 192.168.x.x)
Wel op de router die je aansluit op je gateway.

Iets anders kan ik even zosnel niet verzinnen.

Succes!

[TommyboyNL]

RIP kan alleen aan als NAT uit staat. NAT staat aan, RIP staat uit. Get gateway adres dat mijn router krijgt, is 145.107.8.129 , dus de gateway die mijn pakketjes wegfiltert. Als ik vanaf mijn laptop een "tracepath 8.8.8.8" doe naar 145.107.8.129, dan krijg ik ongeveer de volgende output:

code:

1 192.168.1.100
1 192.168.1.1
1 192.168.1.1
2 No response
3 No response
4 No response
etc...

Of dit er letterlijk stond, weer ik niet, maar wel deze adressen. Morgen zal ik de traces nog een keer doen, en de exacte output posten.

Reset naar factory settings gaat niet helpen, dat ding is nog geen 12 uur uit de doos...

[Raymond P]

Vraag me niet hoe/wat, maar tracepath geeft bij mij soms alleen maar extra stof tot nadenken.
Bijvoorbeeld hierdoor:

code:

ray@main:~$ tracepath -n 8.8.8.8
 1:  10.0.0.15                                             0.185ms pmtu 1500
 1:  10.0.0.1                                              0.448ms 
 1:  10.0.0.1                                              0.316ms 
 2:  10.15.177.129                                         9.044ms 
 3:  84.116.244.65                                         9.761ms asymm  5 
 4:  84.116.134.109                                       10.700ms asymm  5 
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
^C
ray@main:~$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.0.0.1  0.388 ms  0.253 ms  0.255 ms
 2  10.15.177.129  16.560 ms  20.416 ms  20.350 ms
 3  212.142.60.25  20.326 ms  20.314 ms  20.238 ms
 4  84.116.244.65  21.537 ms  24.206 ms  24.188 ms
 5  84.116.136.81  28.091 ms 84.116.130.22  27.875 ms 84.116.134.109  29.968 ms
 6  72.14.214.213  30.117 ms  23.448 ms  26.502 ms
 7  209.85.248.118  115.012 ms 209.85.248.116  26.244 ms  22.419 ms
 8  209.85.255.74  49.146 ms 209.85.255.72  48.622 ms 209.85.255.60  23.629 ms
 9  216.239.49.28  23.712 ms  27.657 ms 216.239.49.38  24.736 ms
10  209.85.255.130  30.302 ms 209.85.255.118  28.008 ms *
11  8.8.8.8  23.610 ms  22.975 ms  22.593 ms

Overigens, packet filtered betekent dat device netjes aangeeft dat ie liever geen ping ontvangt.
Dit betekent niet (automatisch) dat er andere protocollen gefilterd worden.

Ik ben nu best nieuwsgierig hoe ver dat komt eigenlijk.
Een wilde gok is dat pap in de reverse dns van de gateway verwijst naar een point to point netwerk, je 192.168.1.0/24 een reserved range is en het op een of andere manier (dan wel niet door RIP of een andere deftige functie) toch detected wordt aangezien je router zelf wel naar buiten mag.

Nu weet ik uit ervaring dat Linksys equipment niet echt meewerkt aan veranderen van dat soort dingen (Sitecom overigens weer wel), maar probeer je private range is een tikkie te veranderen naar bijvoorbeeld 192.168.2.1/24 of *.4.1/24

En anders is het even wachten op de echte netwerk mannen ben ik bang.

[TommyboyNL]

Okee, we zijn weer op kantoor.
Lokale subnet heb ik veranderd naar 192.168.137.0/24
LAN IP van router is 192.168.137.1
WAN IP van router is 145.107.8.202
LAN IP van laptop is 192.168.1.113

Stapel ping, tracepath en traceroute tests:

code:

tom@Laptop:~$ ping 192.168.137.1
PING 192.168.137.1 (192.168.137.1) 56(84) bytes of data.
64 bytes from 192.168.137.1: icmp_req=1 ttl=64 time=2.89 ms
64 bytes from 192.168.137.1: icmp_req=2 ttl=64 time=2.88 ms
64 bytes from 192.168.137.1: icmp_req=3 ttl=64 time=3.17 ms
64 bytes from 192.168.137.1: icmp_req=4 ttl=64 time=2.88 ms
64 bytes from 192.168.137.1: icmp_req=5 ttl=64 time=2.89 ms

--- 192.168.137.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 2.883/2.945/3.177/0.130 ms

tom@Laptop:~$ ping 145.107.8.202
PING 145.107.8.202 (145.107.8.202) 56(84) bytes of data.
64 bytes from 145.107.8.202: icmp_req=1 ttl=64 time=3.79 ms
64 bytes from 145.107.8.202: icmp_req=2 ttl=64 time=3.74 ms
64 bytes from 145.107.8.202: icmp_req=3 ttl=64 time=3.73 ms
64 bytes from 145.107.8.202: icmp_req=4 ttl=64 time=3.73 ms
64 bytes from 145.107.8.202: icmp_req=5 ttl=64 time=3.72 ms

--- 145.107.8.202 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 3.729/3.746/3.791/0.044 ms

tom@Laptop:~$ ping 145.107.8.129
PING 145.107.8.129 (145.107.8.129) 56(84) bytes of data.

--- 145.107.8.129 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4031ms

tom@Laptop:~$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4031ms

tom@Laptop:~$ tracepath -n 192.168.137.1
 1:  192.168.137.113                                       0.185ms pmtu 1500
 1:  192.168.137.1                                        15.149ms reached
 1:  192.168.137.1                                        15.121ms reached
     Resume: pmtu 1500 hops 1 back 64 

tom@Laptop:~$ tracepath -n 145.107.8.202
 1:  192.168.137.113                                       0.183ms pmtu 1500
 1:  145.107.8.202                                        16.041ms reached
 1:  145.107.8.202                                        15.134ms reached
     Resume: pmtu 1500 hops 1 back 64 

tom@Laptop:~$ tracepath -n 145.107.8.129
 1:  192.168.137.113                                       0.192ms pmtu 1500
 1:  192.168.137.1                                        15.980ms 
 1:  192.168.137.1                                        15.117ms 
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
^C

tom@Laptop:~$ tracepath -n 8.8.8.8
 1:  192.168.137.113                                       0.231ms pmtu 1500
 1:  192.168.137.1                                        18.876ms 
 1:  192.168.137.1                                        15.131ms 
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
^C

tom@Laptop:~$ traceroute -n 192.168.137.1
traceroute to 192.168.137.1 (192.168.137.1), 30 hops max, 60 byte packets
 1  192.168.137.1  35.551 ms  35.535 ms  35.525 ms

tom@Laptop:~$ traceroute -n 145.107.8.202
traceroute to 145.107.8.202 (145.107.8.202), 30 hops max, 60 byte packets
 1  145.107.8.202  3.545 ms  3.497 ms  8.776 ms

tom@Laptop:~$ traceroute -n 145.107.8.129
traceroute to 145.107.8.129 (145.107.8.129), 30 hops max, 60 byte packets
 1  192.168.137.1  3.537 ms  3.510 ms  6.539 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *^C

tom@Laptop:~$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.137.1  3.564 ms  3.514 ms  6.505 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *^C

Met mijn laptop op de muur aangesloten, in plaats van de router:

code:

tom@Laptop:~$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  145.107.8.129  1.348 ms  1.396 ms  1.453 ms
 2  145.107.8.9  11.112 ms 145.107.8.13  10.874 ms 145.107.8.9  11.563 ms
 3  145.107.8.2  12.281 ms  13.963 ms  13.960 ms
 4  145.145.18.110  13.801 ms  14.718 ms  15.192 ms
 5  145.145.80.65  13.692 ms  14.407 ms  17.567 ms
 6  72.14.219.196  18.662 ms  16.881 ms  15.850 ms
 7  209.85.248.116  15.158 ms 209.85.248.118  11.703 ms  22.847 ms
 8  209.85.255.60  54.054 ms 209.85.255.70  52.316 ms 209.85.255.60  51.938 ms
 9  216.239.49.30  15.785 ms 216.239.49.36  25.297 ms 216.239.49.28  16.008 ms
10  * * 209.85.255.130  28.236 ms
11  8.8.8.8  15.666 ms  15.571 ms  25.345 ms

[Petervanakelyen]

En de router gebruikt netjes 145.107.8.129 als gateway?

[Ora et Labora]

Het lijkt wel of jouw router niet naar zijn default gateway gaat?
Je WAN staat op DHCP, wat voor gegevens heeft jouw WAN gekregen?
Als je op de router inlogt kun je dan wel naar buiten pingen in de router, staat ergens onder diagnostics ofzo of een trace maken?
Via je router:
Ping naar de default gateway van jouw router (WAN) (dus het IP van de bestaande gateway)
Ping naar 8.8.8.8
Gaat dat wel goed?

[TommyboyNL]

Doordat ik de kabel steeds tussen de router en mijn laptop heen-en-weer prik, en de absurd korte leasetijd van 15 minuten, heeft de router inmiddels een ander extern IP. Dit moet echter niet van invloed zijn op het eindresultaat.

WAN instellingen op mijn router (verkregen via DHCP)"

code:

Connection Type:    Automatic Configuration - DHCP
Internet IP Address:    145.107.8.205
Subnet Mask:    255.255.255.128
Default Gateway:    145.107.8.129
DNS1:   145.107.15.182
DNS2:   217.117.229.226
DNS3:   
MTU:    1500
DHCP Lease Time:    15 Min

Ping vanaf router:

code:

PING 8.8.8.8 (8.8.8.8): 24 data bytes

32 bytes from 8.8.8.8: icmp_seq=0 ttl=54 Time=16.3 ms

32 bytes from 8.8.8.8: icmp_seq=1 ttl=54 Time=16.2 ms

32 bytes from 8.8.8.8: icmp_seq=2 ttl=54 Time=15.7 ms

32 bytes from 8.8.8.8: icmp_seq=3 ttl=54 Time=15.9 ms

32 bytes from 8.8.8.8: icmp_seq=4 ttl=54 Time=16.3 ms

--- 8.8.8.8 data statistics ---

5 Packets transmitted, 5 Packets received, 0% Packet loss

round-trip min/avg/max = 15.7/16.0/16.3 ms

Traceroute vanaf router:

code:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets

1 1.222 ms 0.535 ms 0.550 ms 145.107.8.129

2 10.970 ms 10.889 ms 10.920 ms 145.107.8.13

3 13.887 ms 14.320 ms 11.438 ms 145.107.8.2

4 11.462 ms 11.365 ms 11.322 ms 145.145.18.110

5 10.920 ms 11.110 ms 11.854 ms 145.145.80.65

6 12.159 ms 11.865 ms 11.274 ms 72.14.219.196

7 11.919 ms 11.497 ms 11.621 ms 209.85.248.116

8 12.652 ms 16.701 ms 11.962 ms 209.85.255.60

9 15.973 ms 34.200 ms 14.936 ms 216.239.49.28

10 17.101 ms 18.035 ms 15.729 ms 209.85.255.130

11 15.715 ms 16.276 ms 15.818 ms 8.8.8.8

Trace complete

[Fairy]

Verwijderd schreef op donderdag 07 juni 2012 @ 23:20:
Beste,

Stel je subnetmasker eens wat ruimer in... 255.0.0.0 ipv 255.255.255.0. (op je dhcp op het private net 192.168.x.x)
Wel op de router die je aansluit op je gateway.

Iets anders kan ik even zosnel niet verzinnen.

Succes!

Van een klassa C naar een onbestaand klasse A netwerk te gaan lijkt me vrij zinloos.

Daarnaast vind ik de ip reeks van het netwerk ook vreemd.


http://bgp.he.net/ip/145.107.8.129

Dat adres lijkt wel van een provider te zijn. Dan zou je dus direct een extern IP moeten hebben.

145.107.8.129 (145.107.8.129.pap.surfnet.utelisys.net)

Announced By
Origin AS Announcement Description
AS1103 145.107.8.0/21 Utelisys Communications BV

Surfnet?

[ Voor 48% gewijzigd door Fairy op 08-06-2012 12:50 ]

[TommyboyNL]

Voor een traceroute met mijn PC direct op de muur, zie onderaan deze post: TommyboyNL in "Router achter router werkt niet"

Voor zover ik weet, zit er geen proxy tussen. De IP reeks is van SURFnet. SURFnet heeft een vrij grote IP range, thuis heb ik een 145.94.*.* adres, wat ook van SURFnet is.

[ Voor 17% gewijzigd door TommyboyNL op 08-06-2012 12:52 ]

[Fairy]

TommyboyNL schreef op vrijdag 08 juni 2012 @ 12:51:
Voor een traceroute met mijn PC direct op de muur, zie onderaan deze post: TommyboyNL in "Router achter router werkt niet"

Voor zover ik weet, zit er geen proxy tussen. De IP reeks is van SURFnet. SURFnet heeft een vrij grote IP range, thuis heb ik een 145.94.*.* adres, wat ook van SURFnet is.

Doe anders eens een MAC clone van de PC die het wel doet op de router. Misschien zit het 'm daar op.

Laat maar, al geprobeerd.

[ Voor 3% gewijzigd door Fairy op 08-06-2012 13:03 ]

[Ora et Labora]

Vanaf je router werkt het dus.
2 opties, of je laptop komt niet door jouw router heen of je laptop word geblocked bij de bestaande gateway, maar zover was je al natuurlijk.
Zit er op je router geen firewall actief of een vreemde static route?
Onderstaand vind ik vreemd, hoe bedoel je dat precies en wat is de reden daartoe?

Lokale subnet heb ik veranderd naar 192.168.137.0/24
LAN IP van router is 192.168.137.1
WAN IP van router is 145.107.8.202
LAN IP van laptop is 192.168.1.113

Waarom niet je WAN van de router op DHCP zoals je nu hebt en je router LAN IP 192.168.1.254 en DHCP uitgeven 192.168.1.1-xxx en een subnet 255.255.255.0?

[ Voor 3% gewijzigd door Ora et Labora op 08-06-2012 13:44 ]

[Petervanakelyen]

Volgens mij heeft hij dat al geprobeerd, maar door onze suggesties ingesteld in een andere range. Dat laatste moet natuurlijk wel 192.168.137.113 zijn.

[Ora et Labora]

Ah Ok sorry dan heb ik niks gezegd, vond het laatste zo vreemd de 192.168.1.113.
Staat trouwens ook in de trace, toch wat beter gaan lezen

Optie is om deze router met dezelfde instellingen op een andere locatie uit te proberen, gewoon achter een bestaande ADSL modem van iemand.
Als hij het dan wel doet weet je in ieder geval zeker dat het niet aan jouw ligt maar aan de bestaande gateway.

[ Voor 74% gewijzigd door Ora et Labora op 08-06-2012 13:49 ]

[TommyboyNL]

Petervanakelyen schreef op vrijdag 08 juni 2012 @ 13:45:
Volgens mij heeft hij dat al geprobeerd, maar door onze suggesties ingesteld in een andere range. Dat laatste moet natuurlijk wel 192.168.137.113 zijn.

Klopt, vlug even verkeerd genoteerd.

EJVL schreef op vrijdag 08 juni 2012 @ 13:44:
Zit er op je router geen firewall actief of een vreemde static route?

Nope, afgezien van een ander lokaal subnet, en een ander wachtwoord, draait de router vrijwel helemaal op fabrieksinstellingen.


Ik zal vanaaf voor de volledigheid de router mee naar huis nemen, en thuis aan mijn netwerk hangen. Ik weet echter vrij zeker dat dat gewoon gaat werken zonder gemor.
Ook ben ik van plan om volgende week hier een router op basis van pfSense te gaan testen, met packet scrubbing aan. Wie weet helpt dat.

[TallManNL]

Heel simpel die router en factory reset geven geprobeerd?

[Petervanakelyen]

Probeer de SPI firewall eens uit te zetten? (+ alles uit te vinken bij 'Security'). Enkel als test, uiteraard.

[Ora et Labora]

Heb je ook logging aanstaan op je router, zie je daar nog wat gebeuren?

Als je router thuis wel gaat werken met exact dezelfde instellingen kan het niet anders dan dat het geblocked word door de Gateway.
Dan zou ik gaan werken met VLAN.
Een switch met 2 VLAN's
VLAN 1 145.107.8.205 untagged op poort 1 met hierin de kabel van de gateway.
VLAN 2 192.168.137.1 /24 untagged op de andere poorten.

Je printer en laptop static IP geven in de 192.168.137.x reeks (of een DHCP servertje gebruiken of de switch DHCP laten geven op deze poorten) en als default gateway het VLAN 2 IP adres op de switch geven.
In de switch nog een static route 0.0.0.0 naar de bestaande gateway.

[ Voor 15% gewijzigd door Ora et Labora op 08-06-2012 14:09 ]

[WhizzCat]

EJVL schreef op vrijdag 08 juni 2012 @ 14:06:
Heb je ook logging aanstaan op je router, zie je daar nog wat gebeuren?

Als je router thuis wel gaat werken met exact dezelfde instellingen kan het niet anders dan dat het geblocked word door de Gateway.
Dan zou ik gaan werken met VLAN.
Een switch met 2 VLAN's
VLAN 1 145.107.8.205 untagged op poort 1 met hierin de kabel van de gateway.
VLAN 2 192.168.137.1 /24 untagged op de andere poorten.

Je printer en laptop static IP geven in de 192.168.137.x reeks (of een DHCP servertje gebruiken of de switch DHCP laten geven op deze poorten) en als default gateway het VLAN 2 IP adres op de switch geven.
In de switch nog een static route 0.0.0.0 naar de bestaande gateway.

No offense, maar dit is echt je reinste flauwekul

Jij probeert nu een Laag3 probleem op te lossen op Laag2.

Wat je hier moet bereiken is NAT achter NAT en dat werk echt prima. Die 145.x.x.x is echter een publiek IP en dit zou dus nog beter moeten werken om dat je maar 1x hoeft te NAT'ten.

TommyboyNL schreef op vrijdag 08 juni 2012 @ 12:20:
Okee, we zijn weer op kantoor.
Lokale subnet heb ik veranderd naar 192.168.137.0/24
LAN IP van router is 192.168.137.1
WAN IP van router is 145.107.8.202
LAN IP van laptop is 192.168.1.113

Dit gaat natuurlijk nooit werken. Je LAN IP reeks is een heel ander subnet dan je laptop

[CyBeR]

TommyboyNL schreef op donderdag 07 juni 2012 @ 15:45:
Routers die ik geprobeerd heb: Sitecom WL-341 V1 001, Linksys E1200.

En die heb je beide gefactory-default (zover ik weet krijg je dan gewoon DHCP op de WAN-poort en NAT naar de rest) en daarna had je met beide hetzelfde resultaat?

Heb je de mogelijkheid om het verkeer tussen je router en je isp te sniffen?

Aangezien SURFnet niet bekend staat om hun vieze netwerktruukjes heb ik 't idee dat ofwel 't NAT-gedeelte mis gaat, ofwel iets anders in jouw netwerk. Voor een ISP is een NAT-device zeer moeilijk te detecteren, dus dat gaat 't echt niet zomaar zijn.

Doe's een ifconfig -a of ipconfig /all als je achter je router hangt?

[ Voor 16% gewijzigd door CyBeR op 08-06-2012 21:56 ]

[Petervanakelyen]

WhizzCat schreef op vrijdag 08 juni 2012 @ 21:25:
Dit gaat natuurlijk nooit werken. Je LAN IP reeks is een heel ander subnet dan je laptop

Lees:

TommyboyNL schreef op vrijdag 08 juni 2012 @ 13:56:
Klopt, vlug even verkeerd genoteerd.

[WhizzCat]

Petervanakelyen schreef op vrijdag 08 juni 2012 @ 22:11:
[...]


Lees:


[...]

Excuseer voor dat, maar die VLAN onzin is nog steeds onzin

Dit topic staat, wat mij betreft, vrij vol met rare adviezen en dingen die kant noch wal raken. Een default standaard SOHO router moet met deze situatie absoluut geen problemen hebben.

De boel resetten naar standaard, inpluggen en gaan.

[Petervanakelyen]

Dat met die VLANs is inderdaad onzin, maar voor de rest denk ik dat we de meest voor de hand liggende problemen toch al hebben besproken. Ik denk het ondertussen overigens ook wel duidelijk is dat "de boel resetten naar factory defaults en gaan" niet werkt in deze situatie.

[ Voor 5% gewijzigd door Petervanakelyen op 08-06-2012 22:36 ]

[Volk]

Kun je eens proberen om de DHCP lease op je WAN poort in te stellen als statisch in te stellen.

Ik heb zelf ooit eens een (statisch) internetadres moeten configureren, maar de Linksys router gaf een foutmelding omdat de gateway volgens de router niet binnen hetzelfde subnet lag als het ip.
Met een custom firmware lukte het toen wel.

[WhizzCat]

Reset naar default is nog niet geprobeerd, dat lees ik nergens (overigens kan ik mij ook idd niet echt voorstellen dat dit veel gaat helpen gezien de leeftijd van 't ding, spiksplinternieuw), maar er is ook met diverse settings gemorreld.

Nogmaals, alle firewalls staan uit? Op de meeste routers zit ook een ingebouwde firewall. SURFnet lijkt mij een provider die echt alleen routeert, althans, dat is mijn ervaring met zulke grote jongens. Vandaar dat jullie "direct uit de muur" ook een publiek IP krijgen. NATting zou gewoon moeten werken.

Allicht heb je de mogelijkheid om het eens met een Vyatta of pfSense doos te proberen (Vyatta vind ik persoonlijk zelf makkelijker en ik kan een werkende config voor je in elkaar zetten mocht je dat willen). Heb je alleen wel een doos met 2 nics nodig.

[TommyboyNL]

Factory settings heb ik inmiddels vaker ingesteld dan de factory zelf. Alle firewalls uit uiteraard ook al geprobeerd. Dat gewoon inpluggen en gaan niet werkt, heb ik ook al gemerkt. Ik heb vaak genoeg netwerken ingesteld, dat hier rare dingen aan de hand zijn, is 100% duidelijk.
Doos met 2 NICs staat al op kantoor, alleen zonder disk. Morgen ga ik weer langs met een disk, en ga ik pfSense instellen. pfSense heb ik genoeg ervaring mee, draai ik thuis ook met een noodzakelijk rare dual-WAN opstelling.
WAN poort op statisch IP instellen ga ik dus NIET doen, dan wordt ik ten eerste gelynched door de andere complexbewoners, en verspeel ik ten tweede alle goodwill bij Utelisys.

[ Voor 8% gewijzigd door TommyboyNL op 10-06-2012 23:46 ]

[_-= Erikje =-_]

ff een switch ertussen en sniffen wat je router (cq OF je router) iets naar buiten stuurt als je er achter vandaan pingt? Je zou haast zeggen dat ie of het verkeer dropt of niet NAT of zo

[Ora et Labora]

WhizzCat schreef op vrijdag 08 juni 2012 @ 21:25:
[...]


No offense, maar dit is echt je reinste flauwekul

Jij probeert nu een Laag3 probleem op te lossen op Laag2.

Wat je hier moet bereiken is NAT achter NAT en dat werk echt prima. Die 145.x.x.x is echter een publiek IP en dit zou dus nog beter moeten werken om dat je maar 1x hoeft te NAT'ten.

Maar waarom is dat onzin dan?
Een router word waarschijnlijk op een of andere manier geblocked bij de gateway, stel dat TS een switch heeft liggen is het toch de moeite van het proberen waard, ook al is het alleen maar voor test?

[WhizzCat]

Omdat een switch gewoon gaat werken. Je krijgt dan echter allemaal publieke IP's op alle apparaten. Dan moet je met access-lists gaan werken en aangezien je met DHCP werkt gaat dat dus niet werken.

Kortom, beter los je dit met NAT op omdat je dan fatsoenlijk kan firewallen.

[Ora et Labora]

Ben het helemaal met je eens dat het veel beter is om met NAT te werken, maar dat werkt niet, dat VLAN gebeuren bedoelde ik ook als test.
Je kunt dat ook een eigen netwerk creëren lokaal als test in private IP met een VLAN en de switch een route 0.0.0.0 naar het publieke IP in een ander VLAN op dezelfde switch.
Je doet dan geen NAT maar een static route over 2 VLANS met de switch als gateway die dat verzorgd en wel met 2 verschillende netwerken een public en private.

[ Voor 9% gewijzigd door Ora et Labora op 11-06-2012 12:16 ]

[CyBeR]

Ho ho. Het is nooit goed om met NAT te werken. Maar in dit geval is het de enige oplossing voor het op handen zijnde probleem.

Anyway. Factory defaults werken blijkbaar niet. Dus dan prop je een switch met mirror mode of een hubje tussen je router en de muur en ga je eens kijken met tcpdump wat er nou eigenlijk uit die router komt.

En ik heb nog steeds die ipconfig/ifconfig niet gezien.

[ Voor 7% gewijzigd door CyBeR op 11-06-2012 13:03 ]

[Zoetjuh]

EJVL schreef op maandag 11 juni 2012 @ 12:15:
Ben het helemaal met je eens dat het veel beter is om met NAT te werken, maar dat werkt niet, dat VLAN gebeuren bedoelde ik ook als test.
Je kunt dat ook een eigen netwerk creëren lokaal als test in private IP met een VLAN en de switch een route 0.0.0.0 naar het publieke IP in een ander VLAN op dezelfde switch.
Je doet dan geen NAT maar een static route over 2 VLANS met de switch als gateway die dat verzorgd en wel met 2 verschillende netwerken een public en private.

Als de andere kant niet weet hoe het verkeer terug moet, werkt dat toch ook niet.. helaas.?
Zeker als het verkeer wordt gerouteerd vanaf een Private subnet ben ik bang dat je snelweg terug vrij leeg blijft.

[laurens0619]

Zou je kunnen kijken of er een optie is op de router om de TTL van de pakketten te veranderen? Dit kan veroorzaken dat het verkeer na de router stopt.

Lees ook hier:
http://forums.fedoraforum.org/showthread.php?t=201360

Ik denk overigens dat NAT verkeer _wel_ wordt geblokkeerd (en ja dat kan prima als de helpdesk het ook niet weet ). Er zijn diverse technieken voor en dacht dat vodafone het ook toepast op tethering verkeer. Ik zou even informeren of er meer mensen in het complex zijn die Natten (en waar het wel werkt)

Lees hier over hoe het geblokkeerd kan worden:
http://www.sflow.org/detectNAT/

en als je iptables op je router hebt zou je het hier waars mee kunnen verhelpen:
http://www.osguides.net/i...-value-with-iptables.html

[ Voor 59% gewijzigd door laurens0619 op 11-06-2012 23:50 ]

[TommyboyNL]

Zo. Uit frustratie dit project even in de ijskast gepropt, maar vanmiddag opnieuw begonnen.
Ik heb besloten het lomp aan te pakken, en heb nu een PC voorzien van meerdere netwerkkaarten, en pfSense geinstalleerd.

ifconfig op pfSense bak:

code:

rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8<VLAN_MTU>
    ether 00:e0:4c:3a:6c:d2
    inet6 fe80::2e0:4cff:fe3a:6cd2%rl0 prefixlen 64 scopeid 0x1 
    inet 145.107.8.230 netmask 0xffffff80 broadcast 145.107.8.255
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8<VLAN_MTU>
    ether 00:02:44:8c:78:b6
    inet6 fe80::202:44ff:fe8c:78b6%rl1 prefixlen 64 scopeid 0x2 
    inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
rl2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8<VLAN_MTU>
    ether 00:02:44:91:d9:f7
    inet6 fe80::202:44ff:fe91:d9f7%rl2 prefixlen 64 scopeid 0x3 
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
    media: Ethernet autoselect (none)
    status: no carrier
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet 127.0.0.1 netmask 0xff000000 
    inet6 ::1 prefixlen 128 
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
pfsync0: flags=0<> metric 0 mtu 1460
    syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
pflog0: flags=100<PROMISC> metric 0 mtu 33200
enc0: flags=0<> metric 0 mtu 1536

ifconfig op Raspberry Pi die via ethernet EN wifi aan de router hangt:

code:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:31:c9:e9  
          inet addr:192.168.1.116  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:449 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:49398 (48.2 KiB)  TX bytes:1150 (1.1 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:0b:81:84:8a:28  
          inet addr:192.168.1.120  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1082 errors:0 dropped:120176 overruns:0 frame:0
          TX packets:468 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:162230 (158.4 KiB)  TX bytes:66839 (65.2 KiB)

ping www.google.nl op pfSense:

code:

PING www-cctld.l.google.com (173.194.78.94): 56 data bytes
64 bytes from 173.194.78.94: icmp_seq=0 ttl=46 time=100.167 ms
64 bytes from 173.194.78.94: icmp_seq=1 ttl=46 time=37.958 ms
64 bytes from 173.194.78.94: icmp_seq=2 ttl=46 time=42.642 ms
64 bytes from 173.194.78.94: icmp_seq=3 ttl=46 time=58.421 ms
64 bytes from 173.194.78.94: icmp_seq=5 ttl=46 time=101.771 ms
64 bytes from 173.194.78.94: icmp_seq=6 ttl=46 time=125.159 ms
64 bytes from 173.194.78.94: icmp_seq=7 ttl=46 time=65.527 ms
64 bytes from 173.194.78.94: icmp_seq=8 ttl=46 time=34.031 ms
64 bytes from 173.194.78.94: icmp_seq=9 ttl=46 time=31.017 ms
64 bytes from 173.194.78.94: icmp_seq=10 ttl=46 time=27.325 ms
^C
--- www-cctld.l.google.com ping statistics ---
11 packets transmitted, 10 packets received, 9.1% packet loss
round-trip min/avg/max/stddev = 27.325/62.402/125.159/33.088 ms

ping www.google.nl Pi:

code:

PING www-cctld.l.google.com (173.194.78.94) 56(84) bytes of data.
From 145.107.8.129.pap.surfnet.utelisys.net (145.107.8.129) icmp_seq=1 Packet filtered
From 145.107.8.129.pap.surfnet.utelisys.net (145.107.8.129) icmp_seq=2 Packet filtered
From 145.107.8.129.pap.surfnet.utelisys.net (145.107.8.129) icmp_seq=3 Packet filtered
From 145.107.8.129.pap.surfnet.utelisys.net (145.107.8.129) icmp_seq=4 Packet filtered
From 145.107.8.129.pap.surfnet.utelisys.net (145.107.8.129) icmp_seq=5 Packet filtered
From 145.107.8.129.pap.surfnet.utelisys.net (145.107.8.129) icmp_seq=6 Packet filtered
From 145.107.8.129.pap.surfnet.utelisys.net (145.107.8.129) icmp_seq=7 Packet filtered
^C
--- www-cctld.l.google.com ping statistics ---
7 packets transmitted, 0 received, +7 errors, 100% packet loss, time 6009ms

Ik zit momenteel weer thuis, en heb alleen SSH toegang tot de router en Pi. Morgen zal ik eens kijken of de TTL wijzigen helpt. Ik heb helaas geen hub of switch met mirror mode in mijn arsenaal, en kan dus nog niet sniffen wat er allemaal verzonden wordt.

[CyBeR]

Op zich heb je nu een router waar je op kunt inloggen. Doe daar 's op:

tcpdump -X -s 0 -evvv -i rl0 src or dst 173.194.78.94

en ping daarna dat ip vanaf zowel de router als de pi (ter vergelijking)

[ Voor 14% gewijzigd door CyBeR op 27-06-2012 22:29 ]

[TommyboyNL]

Aaaah, bedankt voor je reactie!

Als ik vanaf de Pi ping:

code:

22:32:34.331715 00:e0:4c:3a:6c:d2 (oui Unknown) > 00:13:60:f1:bc:d1 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    145.107.8.230.pap.surfnet.utelisys.net > wg-in-f94.1e100.net: ICMP echo request, id 43752, seq 1, length 64
    0x0000:  4500 0054 0000 4000 3f01 a537 916b 08e6  E..T..@.?..7.k..
    0x0010:  adc2 4e5e 0800 5037 aae8 0001 f3ed ea4f  ..N^..P7.......O
    0x0020:  289e 0b00 0809 0a0b 0c0d 0e0f 1011 1213  (...............
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567

Als ik vanaf de router ping:

code:

22:39:48.900142 00:13:60:f1:bc:d1 (oui Unknown) > 00:e0:4c:3a:6c:d2 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 46, id 3630, offset 0, flags [none], proto ICMP (1), length 84)
    wg-in-f94.1e100.net > 145.107.8.230.pap.surfnet.utelisys.net: ICMP echo reply, id 16435, seq 2, length 64
    0x0000:  4500 0054 0e2e 0000 2e01 e809 adc2 4e5e  E..T..........N^
    0x0010:  916b 08e6 0000 b2b0 4033 0002 4feb 6f94  .k......@3..O.o.
    0x0020:  000d 628a 0809 0a0b 0c0d 0e0f 1011 1213  ..b.............
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567

Kan je hier wat mee?

[ Voor 33% gewijzigd door TommyboyNL op 27-06-2012 22:40 ]

[CyBeR]

Die onderste is een reply van google, niet de ping die je stuurde.

[ Voor 76% gewijzigd door CyBeR op 27-06-2012 22:55 ]

[TommyboyNL]

Op pi:

code:

PING 173.194.78.94 (173.194.78.94) 56(84) bytes of data.
From 145.107.8.129 icmp_seq=1 Packet filtered
From 145.107.8.129 icmp_seq=2 Packet filtered
From 145.107.8.129 icmp_seq=3 Packet filtered
From 145.107.8.129 icmp_seq=4 Packet filtered
From 145.107.8.129 icmp_seq=5 Packet filtered
From 145.107.8.129 icmp_seq=6 Packet filtered
From 145.107.8.129 icmp_seq=7 Packet filtered
From 145.107.8.129 icmp_seq=8 Packet filtered
From 145.107.8.129 icmp_seq=9 Packet filtered

et cetera.

Op de router:

code:

22:59:10.193544 00:13:60:f1:bc:d1 (oui Unknown) > 00:e0:4c:3a:6c:d2 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 46, id 13160, offset 0, flags [none], proto ICMP (1), length 84)
    wg-in-f94.1e100.net > 145.107.8.230.pap.surfnet.utelisys.net: ICMP echo reply, id 31625, seq 19, length 64
    0x0000:  4500 0054 3368 0000 2e01 c2cf adc2 4e5e  E..T3h........N^
    0x0010:  916b 08e6 0000 db72 7b89 0013 4feb 741e  .k.....r{...O.t.
    0x0020:  0001 f9e2 0809 0a0b 0c0d 0e0f 1011 1213  ................
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567

[CyBeR]

Ja, maar dat is de reply. De request is een stuk nuttiger

[TommyboyNL]

Whoops, sorry. Tcpdump is nieuw voor mij

Bij deze:

code:

23:09:33.662729 00:e0:4c:3a:6c:d2 (oui Unknown) > 00:13:60:f1:bc:d1 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 29, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    145.107.8.230.pap.surfnet.utelisys.net > wg-in-f94.1e100.net: ICMP echo request, id 1578, seq 1, length 64
    0x0000:  4500 0054 0000 4000 1d01 c737 916b 08e6  E..T..@....7.k..
    0x0010:  adc2 4e5e 0800 131a 062a 0001 9ff6 ea4f  ..N^.....*.....O
    0x0020:  6571 0400 0809 0a0b 0c0d 0e0f 1011 1213  eq..............
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567

[CyBeR]

Ok. Enige serieuze verschil tot dusverre is de lagere ttl.

Vanaf je pi:

ping -t 30 173.194.78.94

Of was dat al vanaf de pi? In dat geval, 31.

[ Voor 17% gewijzigd door CyBeR op 27-06-2012 23:14 ]

[TommyboyNL]

Die laatste was idd vanaf mijn Pi.

Vanaf mijn pi, met -t 31:

code:

23:21:35.212910 00:e0:4c:3a:6c:d2 (oui Unknown) > 00:13:60:f1:bc:d1 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 30, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    145.107.8.230.pap.surfnet.utelisys.net > wg-in-f94.1e100.net: ICMP echo request, id 58905, seq 1, length 64
    0x0000:  4500 0054 0000 4000 1e01 c637 916b 08e6  E..T..@....7.k..
    0x0010:  adc2 4e5e 0800 6e40 e619 0001 70f9 ea4f  ..N^..n@....p..O
    0x0020:  5258 0b00 0809 0a0b 0c0d 0e0f 1011 1213  RX..............
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567
23:21:35.288148 00:13:60:f1:bc:d1 (oui Unknown) > 00:e0:4c:3a:6c:d2 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 46, id 22558, offset 0, flags [none], proto ICMP (1), length 84)
    wg-in-f94.1e100.net > 145.107.8.230.pap.surfnet.utelisys.net: ICMP echo reply, id 58905, seq 1, length 64
    0x0000:  4500 0054 581e 0000 2e01 9e19 adc2 4e5e  E..TX.........N^
    0x0010:  916b 08e6 0000 7640 e619 0001 70f9 ea4f  .k....v@....p..O
    0x0020:  5258 0b00 0809 0a0b 0c0d 0e0f 1011 1213  RX..............
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567

Held! Dat werkte Ik heb succesvol naar buiten kunnen pingen! De Ping is nog steeds om te huilen, en varieert als een malle, maar dat komt doordat er volgens mij een straalverbinding in in het spel is.
Moet ik nu mijn router gewoon de TTL van elk pakketje aan laten passen?

[CyBeR]

Yep. Alternatief is de default ttl op al je hosts ééntje omhoog zetten. Als ik 't goed gok, blokkeren ze packets met een TTL die aangeeft dat er een router involved is. (Wat dus een 'normale' ttl -1 is, dus 29, 63, dat soort zaken.)

Je zou even kunnen kijken of die pfsense build ip stealth ondersteunt:

sysctl -a | grep stealth

en dat dan vervolgens aanzetten als dat iets oplevert. Daarmee zet je het ttl-decrementen uit.

[ Voor 7% gewijzigd door CyBeR op 27-06-2012 23:33 ]

[TommyboyNL]

code:

net.inet.ip.stealth: 0
net.inet6.ip6.stealth: 0

Hieruit maak ik op dat hij dat ondersteunt
Eens kijken of aanzetten werkt. Dankjewel!

[ Voor 20% gewijzigd door TommyboyNL op 27-06-2012 23:36 ]

[CyBeR]

Yep. Je kunt 't nu tijdelijk aanzetten door te doen

sysctl -w net.inet.ip.stealth=1

Ik ken pfSense verder niet, dus hoe je dat permanent maakt, geen idee.

[TommyboyNL]

Heel erg bedankt voor alle hulp. Ik weet nu in elk geval in welke hoek ik het moet zoeken. Morgen eerst maar eens de ISP heel, heul, HEUL hard trappen, want zij beweerden bij hoog en bij laag, dat ze niets deden om routers te ontmoedigen/onklaar te maken.

[Petervanakelyen]

Ik vraag me af wat het nut is van het blokkeren van NAT?

[3DDude]

Petervanakelyen schreef op donderdag 28 juni 2012 @ 00:20:
Ik vraag me af wat het nut is van het blokkeren van NAT?

Surfnet heeft waarschijnlijk genoeg Wan adressen te slijten en uit te delen ?

[CyBeR]

3DDude schreef op donderdag 28 juni 2012 @ 00:25:
[...]

Surfnet heeft waarschijnlijk genoeg Wan adressen te slijten en uit te delen ?

SURFnet is ook niet aan het kutten geslagen hier. Die halen zoals ik al zei dat soort geintjes niet uit in hun netwerk. De toko die tussen TS en SURFnet zit, Utelisys, doet dat.