You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: blog/_posts/2022-12-13-tut-access-to-public-ip-from-vms-containers-using-firewalld.md
+14-12Lines changed: 14 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,40 +11,42 @@ You are running some LXC containers on a host and you use Firewalld to forward p
11
11
12
12
## TL;DR
13
13
- Ordinairly connections from containers to to services which are reached by port forwarding on Firewalld fail, because after outputting the packet to the public interface, it never returns and therefore Firewalld cannot process the port forward.
14
-
- The soloution is destination NAT: `sudo firewall-cmd --zone=trusted --add-rich-rule='rule family="ipv4" destination address="123.123.123.123" forward-port port="80" protocol="tcp" to-port="80" to-addr="10.10.1.20"'`
14
+
- The soloution is destination NAT: `sudo firewall-cmd --zone=trusted --add-rich-rule='rule family="ipv4" destination address="203.0.113.1" forward-port port="80" protocol="tcp" to-port="80" to-addr="10.10.1.20"'`
15
15
16
16
## The Scenario
17
17
You have some LXC containers running on a host, the default LXD setup creates a virtual bridge to which all the containers are connected, they have their own private network say in the 10.10.1.0/24 subnet.
18
18
19
-
You use Firewalld to forward ports from the public internet to the containers. In this scenario when a container does a DNS lookup to which the answer is the public IP address of the LXD host and the container then tries to connect to say port 80 on that public IP it will fail. Why? The HTTP request is received on the input chain by firewalld, no processing is required as it appears to be destined for the public internet. Firewalld outputs the packet to the public interface of the host. Since the HTTP Proxy is not bound to the public interface, it is instead reached via port forwards in Firewalld, the connection fails. This is because Firewalld handles the port forwarding and, after outputting the packet to the public interface, it never returns and therefore Firewalld cannot process the port forward.
19
+
You use Firewalld to forward ports from the public internet to the containers. In this scenario when a container does a DNS lookup to which the answer is the public IP address of the LXD host and the container then tries to connect to say port 80 on that public IP it will fail.
20
+
21
+
Why? The HTTP request is received on the input chain by firewalld, the packet is then output to the public interface of the host. Since the HTTP Proxy is not bound to the public interface the connection fails. It instead must be reached via port forwards in Firewalld. After outputting the packet to the public interface, it never returns and therefore Firewalld cannot process the port forward.
20
22
21
23
## The Solution
22
24
Destination NAT rules in firewalld are the solution here.
23
25
24
26
I understand NAT would appear to be an obvious answer. Indeed if you simply enable masquerading on the zone which contains the container virtual network this will begin to work, this has the unintended consequence of also source NATing all incoming requests to the containers. This means client IPs will no longer visible to applications running in containers.
25
27
26
-
Destination NAT is applied on the input chain, before the routing decision, where it modifies the destination IP address of the packet based. In the example the diagram describes Firewalld recognises that the destination IP for the HTTP request is the public IP of the host. After this it takes the packet and changes the destination IP address to the internal IP address of the Web Proxy Container.
28
+
Destination NAT is applied on the prerouting chain, before the routing decision, where it modifies the destination IP address of the packet based. In the example the diagram describes Firewalld recognises that the destination IP for the HTTP request is the public IP of the host. After this it takes the packet and changes the destination IP address to the internal IP address of the Web Proxy Container.
27
29
28
30
To setup DST-NAT on the example host, you would follow this procedure:
0 commit comments