Today, I learned the shortest command which will determine if a ping from your machine can reach the Internet:

ping 1.1

This parses as 1.0.0.1, which thanks to Cloudflare, is now the IP address of an Internet-facing machine which responds to ICMP pings.

Oh, you can also use this trick to parse 10.0.0.x from `10.x` or 127.0.0.1 from `127.1`. It's just like IPv6's :: notation, except less explicit.

Right, I've been here before.
Our app requires an internet connection, and one of our clients wants to roll it out on a strictly managed network.
We told them which addresses our app communicates with and their network team opened them up for traffic. Should work, right?
Nope, doesn't work.

So I request them to use Fiddler to do some debugging of the network traffic, and lo and behold, it does work when Fiddler is active.
One important detail is that Fiddler uses it's own SSL certificate to debug HTTPS communications. I've had moments where expired certificates were the cause of things not working and running Fiddler "fixes" this because of their own certificate.

So I point this out in numerous mails to their network team, every time I get a response saying "nah, that can't be it".
I keep insisting "I have had this before, please check if any installed Root CA Certificates is expired"
At this point I'm certain they have updates turned off on these machines, and their certificates must not have been updated for a long time.

At one point they come back to me. "Hey, when Fiddler is off, WireShark shows the app communicating with ICMP calls, but when it's on it shows HTTP calls instead".

...YOU'RE THE SUPPOSED NETWORK EXPERTS?! You think data can be send via ICMP? Do you even know what ICMP is? Of course you'll see ICMP calls when the network is rejecting the packages instead of HTTP calls when everything's fine.
(ICMP is used to communicate errors)

I'm trying to keep my patience with these guys until they find exactly what's wrong because even I am somewhat grasping at straws right now. But things like this makes me doubt their expertise...

I programmed an app I've been working on. It sends ICMP packets out...the message I programmed was "One ping to rule them all".

Oh yes, I am the Ping Master ;D

One of my favorite parts of my job is that I’m not allowed to resolve firewall issues myself. IT ops frequently breaks my firewall config, preventing me from resolving any domain names or running dns queries in general even though I still have connectivity. So I call the support number. Remote Desktop icon appears in the corner of my screen.

“Hi I have connectivity but can’t resolve any domain names”
“Have you tried using your browser, maybe they just block pings”
“Well no because I can ping 8.8.8.8, see?”
“Hmm well have you tried from your browser?”
“Yes.”
“Maybe it’s just an issue with ping traffic”
“Well no because I’m not having issues with icmp traffic. I can still ping 8.8.8.8, see?”
“Hmm that’s weird”
*opens network config, renews dhcp lease*
“But I don’t think that’s relat...”
“I know!”
*opens my command prompt, flushes dns cache*
“But if this were a cache issue the requests wouldn’t take so long to tim...”
“I know.”
(Starting to think he doesn’t know)
“I’ll pass this on to the networking guys”
“Thanks”

Third time this has happened. Every time they claim they didn’t change anything and it fixed itself. Obviously this is not the case, because after networking guys “don’t change anything” it starts working again. Every time they talk to me like I have the technical prowess of an HR rep. Like somehow I’m the only software engineer in the world that doesn’t know what the ping command does.

I’m not upset though. They’re just giving me a great excuse to be completely unproductive on a Monday

AHHHHHHHHHHGGGH

I HATE VPN SETUP

- Trying OpenSwan
Installing open swan on a Debian machine.. setting up the config.
Restarting openswan. Syntax error. No syntax error to be found.
Different tutorial.. it starts! Try to connect.. I can’t connect. Look at the logs. No errors.
Tcpdump. My traffic is coming through.. all fine.. try to connect again.. it works! (Nothing changed!)
Try to ping somewhere else.. no connectivity.
Try to ping an IP in the same network.. works fine. So I have connectivity, just no internet.
Spend an hour finding out about traffic directions of which no one seems to know what they really mean.
Boss tells me to stop using openswan because it’s deprecated and replaced by strong swan..

- Strongswan
Reinstall Debian machine, install strongswan. Copy openswan config. Oh, they’re incompatible? Look up strong swan config, and the service starts.
Connect to the VPN.. it works! Again, no internet, just connectivity in the same network. Spend 2h debugging the config, disable firewalls everywhere, find an ancient bug in the Debian package related to my issues.. ok, let’s try compiling from source.. you know what, let’s not. I’ll throw this Debian machine away and try something completely different.

- pfSense
Ok, this looks easy enough! Let’s just click through the initial setup, change some firewall rules, create an L2TP VPN with a simple wizard.
Try to connect to VPN. First, it times out. Maybe a firewall issue? Turn off firewall.. ah, something happens now. I get an error message right after trying to connect to the VPN. Hmm, the port doesn’t even get opened when I enable the firewall.. this implementation seems a bit buggy.. let’s try their OpenVPN module.

Configure OpenVPN. Documentation isn’t that clear.. apparently a client isn’t actually a client but a user is a client.. ok, there’s a hidden checkbox somewhere.
Now where do I download my certificate? Oh, I need a plug-in for that.. ok, interesting. Able to download the certificate, import it, connect and.. YES!!! I can ping! But, I have no DNS..
Apparently, ICMP isn’t getting filtered but all outbound ports are.. yet the firewall is completely disabled. Maybe I need outbound NAT? Oh. There’s no clear documentation on where to configure it. Find some ancient doc, set it up, still no outbound connectivity.

AHAHAHAHHHHHHHHHHG

Then I tried VyOS. I had a great L2TP VPN working in less than 15 mins. Thank you VyOS for actually providing proper docs and proper software.

Just setup an IPsec tunnel and route 192.168.50.0/24 to 192.168.0.0/16 over that tunnel on phase2. We will be able to see 192.168.50.6 machine from 192.168.0.0/16 remote subnet.

Do it.

Why we cannot send ICMP echo from local subnet machine to another machine in same subnet??? Also remote subnet hits only the BSD machine it does not go further. Whyy

I know I should have not done it but SDM and my manager insisted to do so... And now they expect me to fix time outs when remote subnet belongs to different company.