Antsle Forum
Welcome to our Antsle community! This forum is to connect all Antsle users to post experiences, make user-generated content available for the entire community and more.
Please note: This forum is about discussing one specific issue at a time. No generalizations. No judgments. Please check the Forum Rules before posting. If you have specific questions about your Antsle and expect a response from our team directly, please continue to use the appropriate channels (email: [email protected]) so every inquiry is tracked.
Baffling port forwarding problem
Hi all, I've got an ubuntu LXC container set up with a bridged NIC to run Plex. The container grabs an IP on the LAN and from other hosts I can hit plex at port 32400 just fine. The really weird thing is that if I forward 32400 from my router to the container's IP, it doesn't seem to work. No connection is made and the connection attempt seems to hang forever. If I use netcat to listen on 32400 on the antsle itself and forward to that it works fine. I wouldn't expect there to be any iptables shenanigans needed on the antsle if I am using a bridge, is there something I'm missing?
Make sure the VM operating system has a default gateway pointing to the router.
I had papered over the problem with iptables rules on the host but I finally got around to trying your suggestion. After removing the rules I added and replacing the default route going through the internal interface with one to my router, everything works as expected. I would never have figured that out, thanks.
I think I'm having a similar issue.... Here is my work up on it.... Unfortunately, I don't know how/where I should change the route to make it work.
Antsle / pfSense Issue
=====================
I’m not entirely sure where the issue is, so I will describe the environment and the symptoms
of what is happening.
Environment:
———————
I’ve eliminated most of my other network from the equation, unplugging other switches and
connected machines to make sure it isn an external interaction that is causing this.
If have a Netgate pfSense (7100 1U) Firewall appliance connected to my business internet
router. It is configured in a pseudo-bridge mode to hand a small range (13 in all) of static IPs
to my firewall, which then routes them to various internal interfaces sub-nets that are NATted
with an internal IP. All of this works.
I have a Port Forward from my Firewall to an internally connected machine on their respective sub-net
and vice-versus. This provides me access FROM the internet to my internal boxes and vice-versus.
BTW, the HTTP/80 is the only port I’m allowing thru. All of this works.
If I plug my Antsle into a Firewall switch port, instead or alongside the machine that is able to receive
a port forward, it will also reside on the same sub-net, receive it’s IP via DHCP and gain access to
the outside world by exiting thru the NATted sub-net on the firewall. All of this works.
I can then also setup an additional Port Forward to my Antsle from the outside (internet) and access
my Antsle main interface and login to my Antsle from the Internet. All of this works.
I created an antlet and added an additional virtual NIC, so that I can obtain an additional IP directly
on my internal sub-net via DHCP. I then setup a http (NGINX) server on this antlet on port 80. From my
internal sub-net on a different machine, I am able to access the web site running on this antlet. I am also
able to curl to this assigned IP that was assigned directly to my antlet and obtain the page. All of this works.
Issue:
———
If I setup a Port Forward to the IP that is directly attached to the antlet OR if I change a previous Port
Forward to point to it instead of my Antsle, then I CANNOT access my antlet web site from the outside
world. I have confirmed that the firewall allows the rule thru (both for a new port forward or a previously
changed one, just in case I made a typo somewhere on the firewall rule). It appears that the connection
goes thru the firewall, but never returns.
What I don’t know is if the Antsle is somehow ignoring the connection, or if it’s return routing is not allowing
the antlet to talk back to the firewall directly, or does some internal routing need to be configured. I don’t
understand why this works on the main Antlse page, but not for the bridged NIC IP. This issue ONLY exists
with connections coming THRU the firewall. If I do a connection from a machine on the current sub-net,
then I am able to talk to the antlet. If I do a connection THRU the firewall and talk to the Antsle OR any other
web-site NOT on an antlet, then the connection works too.
More Info…:
——————
I don’t know if this is relevant as everything else seems to work. If I ssh into my antlet (the one with the two
interfaces) (first one is bblv and the 2nd one is br0 which correspond to eth0 and eth1 respectively), both
interfaces are present and have the correct IPs obtained by DHCP. If I issue a command of:
ping -I eth0 google.com
then everything seems to go out and back, acknowledging the pings.
If I use a command of:
ping -I eth1 google.com
then I get a “Destination Host Unreachable”
Sample output:
————————
root@externtest:~# ping -c 3 -I eth0 google.com
PING google.com (172.217.3.174) from 10.1.1.11 eth0: 56(84) bytes of data.
64 bytes from sea15s11-in-f14.1e100.net (172.217.3.174): icmp_seq=1 ttl=52 time=12.2 ms
64 bytes from sea15s11-in-f14.1e100.net (172.217.3.174): icmp_seq=2 ttl=52 time=13.7 ms
64 bytes from sea15s11-in-f14.1e100.net (172.217.3.174): icmp_seq=3 ttl=52 time=17.1 ms
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.250/14.393/17.174/2.064 ms
root@externtest:~#
root@externtest:~#
root@externtest:~#
root@externtest:~#
root@externtest:~# ping -c 3 -I eth1 google.com
PING google.com (172.217.3.174) from 10.168.100.29 eth1: 56(84) bytes of data.
From externtest.wgbdev.net (10.168.100.29) icmp_seq=1 Destination Host Unreachable
From externtest.wgbdev.net (10.168.100.29) icmp_seq=2 Destination Host Unreachable
From externtest.wgbdev.net (10.168.100.29) icmp_seq=3 Destination Host Unreachable
--- google.com ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2072ms
pipe 3
root@externtest:~#
root@externtest:~#
Conclusion:
============================
So…. I’m at a lost as to what is going on and whether this issue is with my firewall (pfSense) or with
the internal routing on my Antsle. Any assistances would be greatly appreciated.
Quote from W Glen Boyd on December 2, 2019, 11:19 amI think I'm having a similar issue.... Here is my work up on it.... Unfortunately, I don't know how/where I should change the route to make it work.
...
So…. I’m at a lost as to what is going on and whether this issue is with my firewall (pfSense) or with the internal routing on my Antsle. Any assistances would be greatly appreciated.
As cardboard42 said, it is probably wrong routing in the vm. Your VM should have a default gateway on the interface that connects directly to your router, not the internal one that goes through Antsle's NAT. If you added the second interface and never changed the default settings on the first one, it is almost certainly the case that the default gateway points to wrong interface.
What is probably happening is that connections from the local LAN work because the VM OS knows that the source IP is on a directly attached network. However, when something comes from the Internet, the source IP will be on the Internet. The packet will go to the VM's bridged interface as expected. But the VM has no interface on the network the packet came from, so it will send the response to the default gateway. If the default gateway points to the Antsle side, the response will get dropped because it isn't part of a connection the Antsle's NAT knows about.
In addition, when you open a connection to the Internet from the VM it will "work" but will be going through two NAT translations, one in the Antsle and one in your firewall. If the default gateway is the direct-to-LAN one there will be only one translation in the firewall.
Not being able to ping out the second interface from the Antsle itself is normal. The Antsle OS itself won't have an IP associated with that interface, only the VM's attached to it will.