Tag Archives: networking

How to setup dual-stack IPv4 IPv6 Azure VM without a load-balancer

I wanted to document my Microsoft Azure saga in getting a public IPv6 address to work in a virtual machine without a load balancer in front of it. My needs were pretty simple and straightforward I wanted a virtual server that had a static IPv4 and IPv6 public addresses so that I can monitor my home network and other websites.

You would think this would be pretty easy, a few clicks and done? That wasn’t my experience on Azure and setting this up isn’t easy nor straightforward. Below is how to get it done, if this helps you – you can buy me a coffee or beer.

Continue reading

OPNsense firewall on Proxmox fix ‘no internet’

Quick post to note how I determined and then fixed the internet access issue I was having when I installed OPNsense on Proxmox.

OPNsense virtual machine is configured with VirtiO network drivers.

Other than the obvious “I can’t access anything on the internet” or can’t reach external IP addresses problem I looked at troubleshooting via nmap – because the devices on the network could ping externally (8.8.8.8) and also resolve DNS requests.

In a broken state you may see ‘tcpwrapper’ when testing a known host serving HTTP, like so:

root@test:~# nmap -p 80 -sV 216.58.194.206

Starting Nmap 7.40 ( https://nmap.org ) at 2018-11-17 17:54 UTC

Nmap scan report for sfo03s01-in-f206.1e100.net (216.58.194.206)

Host is up (0.010s latency).

PORT   STATE SERVICE    VERSION

80/tcp open  tcpwrapped

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 7.91 seconds

To fix this issue, ensure that “Disable hardware checksum offload” is  enabled in the OPNsense interface, then reboot the firewall for changes to take effect.

After a reboot, doing another test via nmap will actually respond with HTTP fingerprints, as expected and internet is back.

root@test:~# nmap -p 80 -sV 216.58.194.206

Starting Nmap 7.40 ( https://nmap.org ) at 2018-11-17 18:00 UTC

Nmap scan report for sfo03s01-in-f14.1e100.net (216.58.194.206)

Host is up (0.0096s latency).

PORT   STATE SERVICE VERSION

80/tcp open  http    gws

1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :

SF-Port80-TCP:V=7.40%I=7%D=11/17%Time=5BF0574C%P=x86_64-pc-linux-gnu%r(Get

SF:Request,8A7A,"HTTP/1\.0\x20200\x20OK\r\nDate:\x20Sat,\x2017\x20Nov\x202

SF:018\x2018:00:43\x20GMT\r\nExpires:\x20-1\r\nCache-Control:\x20private,\

SF:x20max-age=0\r\nContent-Type:\x20text/html;\x20charset=ISO-8859-1\r\nP3

SF:P:\x20CP=\"This\x20is\x20not\x20a\x20P3P\x20policy!\x20See\x20g\.co/p3p

SF:help\x20for\x20more\x20info\.\"\r\nServer:\x20gws\r\nX-XSS-Protection:\

SF:x201;\x20mode=block\r\nX-Frame-Options:\x20SAMEORIGIN\r\nSet-Cookie:\x2

SF:01P_JAR=2018-11-17-18;\x20expires=Mon,\x2017-Dec-2018\x2018:00:43\x20GM

SF:T;\x20path=/;\x20domain=\.google\.com\r\nSet-Cookie:\x20NID=146=0dp1WLb

SF:UhFIr1MIVwhAglx_4O6x-0eJHrmYFTov9a3oFxE2-lZSUI_9mmKBFXQZjYbjKbSRiirLZ-U

SF:cfybTiNQR_vmHD2MY4RBHP-hj4K7oyQX4lXuCgrSU7ESRXiX2Jn0qwoLWvvEItnC2hgDHEb

SF:oLJffQrfiEazdGDp5XppPU;\x20expires=Sun,\x2019-May-2019\x2018:00:43\x20G

SF:MT;\x20path=/;\x20domain=\.google\.com;\x20HttpOnly\r\nAccept-Ranges:\x

SF:20none\r\nVary:\x20Accept-Encoding\r\n\r\n<!doctype\x20html><html\x20it

SF:emscope=\"\"\x20itemtype=\"http://schema\.org/WebPage\"\x20lang=\"en\">

SF:<head><meta\x20content=\"Search\x20the\x20world's\x20information,\x20in

SF:cluding\x20webpages,\x20images,\x20videos\x20and\x20more\.\x20Google\x2

SF:0has\x20ma")%r(HTTPOptions,71B,"HTTP/1\.0\x20405\x20Method\x20Not\x20Al

SF:lowed\r\nAllow:\x20GET,\x20HEAD\r\nDate:\x20Sat,\x2017\x20Nov\x202018\x

SF:2018:00:44\x20GMT\r\nContent-Type:\x20text/html;\x20charset=UTF-8\r\nSe

SF:rver:\x20gws\r\nContent-Length:\x201592\r\nX-XSS-Protection:\x201;\x20m

SF:ode=block\r\nX-Frame-Options:\x20SAMEORIGIN\r\n\r\n<!DOCTYPE\x20html>\n

SF:<html\x20lang=en>\n\x20\x20<meta\x20charset=utf-8>\n\x20\x20<meta\x20na

SF:me=viewport\x20content=\"initial-scale=1,\x20minimum-scale=1,\x20width=

SF:device-width\">\n\x20\x20<title>Error\x20405\x20\(Method\x20Not\x20Allo

SF:wed\)!!1</title>\n\x20\x20<style>\n\x20\x20\x20\x20\*{margin:0;padding:

SF:0}html,code{font:15px/22px\x20arial,sans-serif}html{background:#fff;col

SF:or:#222;padding:15px}body{margin:7%\x20auto\x200;max-width:390px;min-he

SF:ight:180px;padding:30px\x200\x2015px}\*\x20>\x20body{background:url\(//

SF:www\.google\.com/images/errors/robot\.png\)\x20100%\x205px\x20no-repeat

SF:;padding-right:205px}p{margin:11px\x200\x2022px;overflow:hidden}ins{col

SF:or:#777;text-decoration:none}a\x20img{border:0}@media\x20screen\x20and\

SF:x20\(max-width:772px\){body{background:none;margin-top:0;max-width:none

SF:;padding");

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 52.89 seconds

root@test:~#

Allow non-root processes to bind to privileged (ports <1024) on linux

As I work on my homelab migration from FreeNAS into Linux containers, I need to move my freebsd jails to LXC.

In *nix any usage of well-known ports (aka 1024 or less) requires special privileges or a kernel setting. In FreeBSD a simple sysctl net.inet.ip.portrange.reservedhigh =1 was enough to allow the BSD jail to use any port on the jail.

On LXC, I had to figure out how to do the same thing and its quite different. My environment is a debian stretch LXC container but should work on other linux versions.

# apt-get install libcap2-bin
# setcap 'cap_net_bind_service=+ep' /usr/bin/transmission-daemon

In the example above, the binary /usr/bin/transmission-daemon is now able to open any port, or port 80 http in my case all while running a service as a non-root user.

Hopefully these helps folks out there, the answer took some digging but I already had an idea on what was needed thanks to my FreeBSD experience in zones 🙂

Troubleshooting networking issues after fresh install of proxmox VE 4.4

Writing a quick troubleshooting guide and informative post to address an issue I came across when installing Proxmox VE 4.4 on two of my machines.

On servers with more than two network interfaces Debian/Proxmox renames all interfaces and does not properly detect eth0 as the on-board ethernet as many other linux flavors. This may cause a mild headache if you just installed Proxmox with static IP addresses using the installer and upon reboot you can’t access any network resources. Continue reading