Archive for the ‘Network-and-equipment’ Category
Posted by jpluimers on 2016/03/28
20150412 ping statistics from WiFi -> ADSL -> VPN -> fiber (where ADSL and fiber both are Fritz!Box machines having LAN-LAN VPN to each other):
PING 192.168.71.1 (192.168.71.1): 56 data bytes
64 bytes from 192.168.71.1: icmp_seq=0 ttl=63 time=19.190 ms
...64 bytes from 192.168.71.1: icmp_seq=1 ttl=63 time=18.905 ms
64 bytes from 192.168.71.1: icmp_seq=2 ttl=63 time=19.261 ms
64 bytes from 192.168.71.1: icmp_seq=3 ttl=63 time=19.982 ms
64 bytes from 192.168.71.1: icmp_seq=4 ttl=63 time=19.332 ms
64 bytes from 192.168.71.1: icmp_seq=5 ttl=63 time=26.800 ms
64 bytes from 192.168.71.1: icmp_seq=6 ttl=63 time=20.139 ms
64 bytes from 192.168.71.1: icmp_seq=7 ttl=63 time=19.498 ms
64 bytes from 192.168.71.1: icmp_seq=8 ttl=63 time=18.915 ms
64 bytes from 192.168.71.1: icmp_seq=9 ttl=63 time=19.200 ms
64 bytes from 192.168.71.1: icmp_seq=10 ttl=63 time=18.948 ms
64 bytes from 192.168.71.1: icmp_seq=11 ttl=63 time=19.524 ms
64 bytes from 192.168.71.1: icmp_seq=12 ttl=63 time=19.511 ms
64 bytes from 192.168.71.1: icmp_seq=13 ttl=63 time=20.417 ms
64 bytes from 192.168.71.1: icmp_seq=14 ttl=63 time=19.350 ms
64 bytes from 192.168.71.1: icmp_seq=15 ttl=63 time=18.690 ms
64 bytes from 192.168.71.1: icmp_seq=16 ttl=63 time=18.632 ms
64 bytes from 192.168.71.1: icmp_seq=17 ttl=63 time=18.912 ms
64 bytes from 192.168.71.1: icmp_seq=18 ttl=63 time=19.397 ms
64 bytes from 192.168.71.1: icmp_seq=19 ttl=63 time=19.257 ms
64 bytes from 192.168.71.1: icmp_seq=20 ttl=63 time=18.147 ms
64 bytes from 192.168.71.1: icmp_seq=21 ttl=63 time=18.601 ms
^C
--- 192.168.71.1 ping statistics ---
22 packets transmitted, 22 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.147/19.573/26.800/1.657 ms
same but LAN –> fiber -> VPN -> ADSL
Pinging 192.168.24.1 with 32 bytes of data:
Reply from 192.168.24.1: bytes=32 time=19ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=18ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Reply from 192.168.24.1: bytes=32 time=17ms TTL=63
Ping statistics for 192.168.24.1:
Packets: Sent = 24, Received = 24, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 19ms, Average = 17ms
–jeroen
Posted in ADSL, fiber, Fritz!, Fritz!Box, Internet, Network-and-equipment, Power User, routers, VPN | Leave a Comment »
Posted by jpluimers on 2016/03/18
Nice summary for just saying “Use Tunnelblick”
This howto article explains how to obtain and setup a Mac openvpn client to connect to the OpenVPN Access Server.
Source: How to connect to Access Server from a Mac
–jeroen
Posted in Apple, Mac, Mac OS X / OS X / MacOS, Mac OS X 10.5 Leopard, Mac OS X 10.6 Snow Leopard, Mac OS X 10.7 Lion, MacBook, MacBook Retina, MacBook-Air, MacBook-Pro, MacMini, OpenVPN, OS X 10.11 El Capitan, OS X 10.8 Mountain Lion, OS X 10.9 Mavericks, Power User | Leave a Comment »
Posted by jpluimers on 2016/03/18
Mikrotik have statistics and way more features. The most lacking or disturbing features on the TP-LINK (none of which are mentioned in their documentation):
- The documentation mentions you can enable Enable Bandwidth Based Balance Routing then select the WAN connections to combine but that doesn’t work at all, even if you follow the bandwidth steps carefully.
- Balanced Routing work when you perform these steps as mentioned at time point 457 in this video https://youtu.be/YDUfP8a5zNY
- Enable Application Optimized Routing
- Enable Bandwidth Based Balance Routing
- Virtual-Server table can only handle 32 incoming port redirects; you get the message “Cannot add more than 32 Virtual Server entries” like in the picture below.
- No IPv6 support
- No way to show any statistics as graphs.
- Every once in a while the web interface becomes really really slow which only a reboot can resolve.
- You cannot have one of the WAN connections have multiple IP addresses.
- Local DHCP clients are not added to the DNS proxy which means you cannot resolve them by name.
- TCP Sequence Prediction: Difficulty=0 (Trivial joke)
- You cannot configure how often to check WAN connections
On the other hand: when you do balanced routing indeed bundles all the WAN connections, configured Virtual Servers do work well and WAN specific routing settings to what they need to.
Source: Gigabit Load Balance Broadband Router TL-ER5120 – Welcome to TP-LINK
Verdict: fine for home use, not good for real multi-WAN use.
–jeroen
Read the rest of this entry »
Posted in Internet, Power User, routers | 1 Comment »
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 »
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 »
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 »
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 »
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 »
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 »
The Wiert Corner - irregular stream of stuff 