The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,839 other subscribers

Archive for the ‘Network-and-equipment’ Category

« Previous Entries
Next Entries »

Fritz!Box 7360 and 7490: static routes over VPN don’t work

Posted by jpluimers on 2016/03/15

I’ve tried the below on a Fritz!Box 7490 configuration and it fails as well.

The case is that I’ve a VPN (see Getting Fritz!Box LAN-LAN VPN to work) between a Fritz!Box 7360 (having internal IP 192.168.24.1) and a Fritz!Box 7490 (having internal IP 192.168.71.1). This is how it looks from the Fritz!Box 7360 side:

Name Address in the Internet local network remote network
80.100.143.119 80.100.143.119 192.168.24.0/24 192.168.171.0/24

On the 192.168.171.0/24 side of things, the internal IP of the 80.100.143.119 router is 192.168.171.1. Inside the 192.168.171.0/24 network is is another router (192.168.171.22) having an internal 192.168.71.0/24 network.

Basically I want to tell the Fritz!Box 7360 (at IP 192.168.24.1) that there is an internal route to 192.168.71.0/24 via 192.168.171.22.

I found and read Accessing multiple IP networks behind a FRITZ!Box over VPN connection between two FRITZ!Boxes | FRITZ!Box 7360 | AVM International.

Based on it, I wanted to add this route on the 192.168.24.1:

Static IPv4 Route

IPv4 network 192.168.71.0
Subnet mask 255.255.255.0
Gateway 192.168.171.22
Enabled X

When you do that, you get this error message:

An error occurred.
Error description: The route is illegal.
Please enter your data again. If the error occurs again, please consult AVM Support.

How can I get this route to work?

–jeroen

Posted in Fritz!, Fritz!Box, Internet, Power User | 1 Comment »

VPN over HTTPS: Ultimate Powerful VPN Connectivity – SoftEther VPN Project

Posted by jpluimers on 2016/02/01

This is cool, as it allows to run VPN over HTTPS or even over ICMP or DNS. Impressive: 1. Ultimate Powerful VPN Connectivity – SoftEther VPN Project.

Equally impressive is the range of operating systems covered:

  • Windows (98 until Server 20012 with x86 and x64 implementations).
  • Linux Kernels 2.4, 2.6 and 3.x on Intel x86, x64, ARM, MIPS and PowerPC platforms.
  • FreeBSD 5.x, 6.x, 7.x, 8.x and 9.x are supported on Intel x86 and x64 platforms.
  • Solaris 8, 9, 10 and 11 on Intel x86, Intel x64, SPARC (both 32 bit and 64 bit) platforms.
  • Mac OS X 10.4, 10.5, 10.6, 10.7 and 10.8 on Intel x86, Intel x64, PowerPC (32 bit) and PowerPC G5 (64 bit) platforms.

–jeroen

Posted in Network-and-equipment, Power User, VPN | Leave a Comment »

VLAN with multiple AP’s on Tomato? | LinksysInfo.org

Posted by jpluimers on 2016/01/26

Interesting: VLAN with multiple AP’s on Tomato? | LinksysInfo.org

Some additional links for back-ground info:

–jeroen

Posted in Internet, Power User, routers, TomatoUSB | Leave a Comment »

Getting Fritz!Box LAN-LAN VPN to work for @xs4all connections despite lack of @AVM_DE support

Posted by jpluimers on 2016/01/22

This is a follow-up of my post Fritz!Box VPN error messages.

I had been failing to get a LAN-LAN connection between two xs4all Fritz!Box internet connections working, despite the description in [WayBack] Adapting a VPN connection from FRITZ!Box to FRITZ!Box (LAN-LAN) | AVM International.

I was keeping the 0x1C error, and eventually contacted the customer support. At first they redirected me again to the documentation, so I replied with detailed PDFs for both Fritz!Box devices containing detailed information about:

  • both their internet connectivity
  • both their internal network settings
  • both their error logs
  • both their VPN configuration (including LAN-LAN and personal entries)

I got a reply back that – paraphrased – went like “We cannot provide network-administration-support, but VPN support of Fritz!Box in general works fine, so please read these pages”:

Given that they knew both connections were xs4all (which out-of-the-box doesn’t firewall), the PDFs didn’t indicate any firewall configuration and support not asking if the individual VPN connections worked (they do) but just blaming me or the Firewall is blatant, especially since they did not explain what the error codes meant.

Besides I already had read those pages and tried all the suggested solutions (more than a day work, as there are many suggested steps, Fritz!Box devices tend to reboot on many configuration change types and their DSL training is slow at best).

After the email, I went back to the drawing board based in this one twitter conversation that was partially useful (but failed to indicate more error codes and also pointed me to their email helpdesk which failed miserably).

The IKE-error 0x1C can mean that the remote IP doesn’t match the expected IP.

So I tried this:

Read the rest of this entry »

Posted in Fritz!, Fritz!Box, Hardware, Network-and-equipment, Power User | 1 Comment »

[NL] @xs4all – inkomende telefoontjes blokkeren: Fritz!Box of VOIP-selfcare

Posted by jpluimers on 2016/01/18

xs4all biedt twee mogelijkheden om inkomende telefoontjes te blokkeren: via de Fritz!Box of via VOIP-selfcare.

Als je in het VOIP-selfcare een nummer toevoegt onder “Inkomende oproepen blokkeren”, dan krijgt de beller een “bandje” dat het een ongewenst gesprek is. Dat wilde ik niet: net als bij inlog fouten wil je zo weinig mogelijk informatie geven over een oorzaak.

Als je oproepen van een specifiek telefoonnummer via de Fritz!Box blokkeert, dan krijgt de beller meteen xs4all voicemail. Ook niet wat ik wilde, maar het zette me wel op het juiste spoor.

De voicemail komt doordat de Fritz!Box dan een meteen een in-gesprek (line busy) genereert en zo het telefoongesprek afwimpelt. Omdat voicemail bij xs4all standaard aan staat, gaat het gesprek dan meteen naar voicemail.

In dit geval wilde ik toch van de xs4all voicemail af, dus heb ik dat gedaan door in de VOIP-self care alle vinkjes bij “Gesprekken doorschakelen” uit te zetten, zie het plaatje onderaan.

Een “Gesprekken doorschakelen” zonder vinkjes heft alle doorschakelingen op, waardoor de beller precies het antwoord krijgt dat de Fritz!Box voorschotelt.

Read the rest of this entry »

Posted in Fritz!, Fritz!Box, Internet, Power User | Leave a Comment »

Fritz!Box VPN error messages – via: VPN mit der FritzBox :: network lab

Posted by jpluimers on 2015/11/02

VPN mit der FritzBox :: network lab has a nice walk through on how to set up non LAN-LAN VPN connections with Fritz!Box.

But the really cool thing is that they have a table of IKE (Internet Key Exchange) error messages.

Until now, I mainly had these errors, which thanks to the table now have a description:

Better than

Note: both are within the public IP range, so not in the ranges mentioned here: Identifying the address range of the IPv4 address for the Internet connection | FRITZ!Box 7390 | AVM International.

Maybe I should just use the Windows tools to setup the config: MarkusKirschmann.de – Blog » IKE-Error Ox1c.

–jeroen

via:

Their table:

Read the rest of this entry »

Posted in Fritz!, Fritz!Box, Network-and-equipment, Power User | Leave a Comment »

network, multicast and send address in TransportNetwork; via Digging into Tibco Rendezvous network details – II

Posted by jpluimers on 2015/10/28

Tibco is very powerful and can do all sorts of casting.

For my memory (formatted for readability; there are more details at OpenPGM Concepts : Transport):

The network parameter consists of up to three parts, separated by semicolons—network, multicast groups, send address—as in these examples:

Example Meaning
lan0 network only
lan0;225.1.1.1 one multicast group
lan0;225.1.1.1,225.1.1.5;225.1.1.6 two multicast groups, send address
lan0;;225.1.1.6 no multicast group, send address

The format is like this:

partOne;partTwo;partThree

and some bits are optional

partOne[;[partTwo][;[partThree]]]

Part one identifies the network, which you can specify in several ways: – Host name, Host IP address, Network name, Network IP number, Interface name, Default TRDP daemons use the network interface which corresponds to the hostname of the system as determined by the C function gethostname(). PGM daemons use the default PGM multicast interface, 224.0.1.78.

Part Two—Multicast Groups – Part two is a list of zero or more multicast groups to join, specified as IP addresses, separated by commas. Each address in part two must denote a valid multicast address. Joining a multicast group enables listeners on the resulting transport to receive data sent to that multicast group.

Part Three—Send Address, Part three is a single send address. When a program sends multicast data on the resulting transport, it is sent to this address. (Point-to-point data is not affected.) If present, this item must be an IP address—not a host name or network name. The send address need not be among the list of multicast groups joined in part two. If you join one or more multicast groups in part two, but do not specify a send address in part three, the send address defaults to the first multicast group listed in part two.

Note: I wasn’t aware that for Tibco Rendezvous the default multi-cast network was 225 (often you see 224 here, as that is the starting multi-cast range in the IANA IPv4 Address Space list)

–jeroen

via:

Posted in Communications Development, Development, Internet protocol suite, Network-and-equipment, Software Development, TCP, TIBCO Rendezvous | Leave a Comment »

Fiber to Fiber speed beats Cable to Fiber speed by a factor 2 (all three internet connections are in the same house)

Posted by jpluimers on 2015/10/05

I’ve two fiber connections, one cable connection and one ADSL connection at home.

This is a traceroute from one fiber connection to the other over the outside network:

traceroute to snip.xs4all.nl (80.100.143.119), 64 hops max, 52 byte packets
 1  tomatortn66u (172.23.71.1)  0.951 ms  0.708 ms  0.638 ms
 2  fiber24315337241.heldenvannu.net (37.153.243.241)  1.135 ms  0.988 ms  0.974 ms
 3  rt121bb121-212-183.routit.net (212.121.121.183)  1.973 ms  1.976 ms  1.919 ms
 4  0-7-0-4-core2-a-tc1.routit.net (84.246.25.133)  2.711 ms  2.498 ms  2.517 ms
 5  0-7-0-4-core2-a-tc1.routit.net (84.246.25.133)  2.725 ms  2.674 ms  2.535 ms
 6  0-7-0-7-core4-a-tc2.routit.net (37.0.80.7)  3.048 ms  2.883 ms  2.712 ms
 7  1-2-inet1-tc2.routit.net (84.246.25.46)  2.767 ms  2.633 ms  2.514 ms
 8  ams-ix.tc2.xs4all.net (80.249.208.166)  2.676 ms  4.177 ms  2.775 ms
 9  0.ae5.xr3.3d12.xs4all.net (194.109.5.13)  2.987 ms  3.114 ms  11.387 ms
10  xe-8-1-0.dr11.xs4all.net (194.109.7.14)  6.188 ms
    xe-7-0-1.dr11.d12.xs4all.net (194.109.7.58)  3.320 ms
    xe-8-0-1.dr11.d12.xs4all.net (194.109.7.38)  3.206 ms
11  snip.xs4all.nl (80.100.143.119)  4.079 ms !X  3.960 ms !X  3.946 ms !X

This is the same but from my third connection (that will go away sooner than later): Cable.

traceroute to snip.xs4all.nl (80.100.143.119), 64 hops max, 52 byte packets
 1  www.asusnetwork.net (192.168.171.1)  1.016 ms  0.983 ms  0.938 ms
 2  * * *
 3  212.142.62.69 (212.142.62.69)  11.427 ms  8.361 ms  8.459 ms
 4  84.116.244.97 (84.116.244.97)  8.080 ms  10.405 ms  7.340 ms
 5  nl-ams09b-ri1-xe-10-2-0.aorta.net (84.116.130.22)  7.625 ms
    nl-ams09b-ri1-xe-8-0-0.aorta.net (84.116.130.2)  10.392 ms
    84.116.136.81 (84.116.136.81)  9.534 ms
 6  0.xe-1-2-0.xr1.tc2.xs4all.net (194.109.7.209)  8.315 ms  9.505 ms  9.684 ms
 7  0.ae5.xr3.3d12.xs4all.net (194.109.5.13)  9.508 ms
    0.ae4.xr4.1d12.xs4all.net (194.109.5.9)  9.565 ms
    0.ae5.xr3.3d12.xs4all.net (194.109.5.13)  9.459 ms
 8  xe-7-0-1.dr11.d12.xs4all.net (194.109.7.58)  8.547 ms  13.159 ms  9.893 ms
 9  snip.xs4all.nl (80.100.143.119)  9.710 ms !X  10.079 ms !X  8.121 ms !X

Finally there is ADSL (which will go even sooner):

snap:~ # traceroute snip.xs4all.nl
traceroute to snip.xs4all.nl (80.100.143.119), 30 hops max, 40 byte packets using UDP
 1  192.168.71.1 (192.168.71.1)  1.052 ms   0.554 ms   0.520 ms
 2  lo0.dr13.d12.xs4all.net (194.109.5.212)  17.767 ms   17.368 ms   17.123 ms
 3  1423.ae3.xr4.1d12.xs4all.net (194.109.7.137)  16.901 ms 1418.ae3.xr4.1d12.xs4all.net (194.109.7.17)  16.628 ms 1323.ae3.xr3.3d12.xs4all.net (194.109.7.141)  16.354 ms
 4  xe-8-1-0.dr11.xs4all.net (194.109.7.14)  15.961 ms xe7-0-0.dr11.d12.xs4all.net (194.109.7.170)  15.762 ms xe-8-1-0.dr11.xs4all.net (194.109.7.14)  15.283 ms
 5  snip.xs4all.nl (80.100.143.119)(N!)  15.914 ms (N!)  16.171 ms (N!)  15.710 ms

Cable is about twice as slow than Fiber.

ADSL is about three times as slow than Fiber.

–jeroen

Posted in fiber, Fritz!, Fritz!Box, Internet, Power User, routers, TomatoUSB | Leave a Comment »

http://169.254.1.1 trick for Opening UI of the FRITZ!WLAN Repeater 1750E – via: AVM International

Posted by jpluimers on 2015/08/24

Because http://fritz.box points to my Fritz!BOX router, it cannot be used to get to my Fritz!WLAN Repeater. I just learned about the http://169.254.1.1 trick does.

Which saves me from remembering the repeater IP-address or name.

–jeroen

via: Opening the FRITZ!Box user interface | FRITZ!WLAN Repeater 1750E | AVM International.

Posted in Fritz!, Fritz!Box, Fritz!WLAN, Internet, Power User, routers | Leave a Comment »

Setting your DNS servers manually – via – Tweakers

Posted by jpluimers on 2015/08/21

Interesting Dutch thread about a major ISP having DNS issues because of DDos attacks. Many messages to set your DNS servers manually on various operating systems, and a list of good DNS server alternatives. Recommended reading:

Ziggo kampt weer met storing – update – IT Pro – Nieuws – Tweakers.

–jeroen

Posted in Internet, Power User, routers | Leave a Comment »

« Previous Entries
Next Entries »