Reverse Beacon Network spots using my EFHW and QRP 6 watts
Stefan Helander

Why I love end fed half wave (EFHW) antennas

/0 Comments/in /by

The antenna seems always to be a compromise between practical matters and performance. While not being the most high performance antenna, I find the end fed half wave (EFHW) a very practical antenna, especially during portable operations.

The EFHW doesn’t need to be straight. It can be bent in angles and be “abused” a lot.

In this video I have a temporary installation in a vacation home (time share) where I am not able to erect any masts, not being able to use trees or other houses as fixation points for my antenna. I used some zip ties only that can be removed without leaving any marks.

The antenna height is far from optimal and the antenna is bent several times. It is also close to the rain gutters made of metal. Still I have fine SWR levels on all bands (10/15/20/40 m) and can work all of Europe on my QRP rig (6 watts) (see the screenshot from Reverse Beacon Network).

Stefan Helander

pfSense port forward to a NAT:ed IP-address located on the other side of a ipsec tunnel

/0 Comments/in /by

This is kind of a special scenario but actually occured for me. A port on the pfSense WAN should be NAT:ed to an IP-address located on a remote subnet via an ipsec tunnel. The problem here was the router on the other end of the tunnel did not route all it’s outgoing traffic over the tunnel. Only a few subnets behind the pfSense went through the tunnel. All other traffic was using the routers normal Internet connection.

In the image above, a port (123 in the example code below) on the pfSense (100.1.1.1) should be NAT:ed and port forwarded to 10.0.0.7. The result was the NAT:ed port forwarded packets reached the intended host (10.0.0.7) but replies probably went straight back on the internet, not going back through the tunnel.

I solved this by setting up a simple proxy on a server using iptables located on a machine in one of the subnets at the pfSense site which was reachable from 10.0.0.7 through the tunnel. See next image.

The proxy was made using iptables in a Ubuntu machine on 10.2.2.2. Both the proxy server on 10.2.2.2 and the host 10.0.0.7 could reach each other over the ipsec tunnel.

In pfSense I changed the NAT / port forward of port 123 from 10.0.0.7 to 10.2.2.2 (and deleted the existing states in pfsense from my previous tries, until I did that, this didn’t work).

The proxy server using IP-tables was set up like this (guide found here):

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i ens160 -p udp --dport 123 -j DNAT --to 10.0.0.7
sudo iptables -t nat -A POSTROUTING -o ens160 -p udp --dport 123 -j SNAT --to-source 10.2.2.2
sudo iptables -t nat -A POSTROUTING -p udp --sport 123 -j SNAT --to-source 10.2.2.2

You will probably want to make sysctl ip_forward and iptables statements persistent over reboots.