[lxc-users] lxd host can not access container via domain

Sun Sep 3 00:52:12 UTC 2017

On 09/02/2017 03:36 PM, Benjamin Asbach wrote:
> On 2017-09-02 06:13, Mike Wright wrote:
>> On 09/01/2017 07:02 PM, Benjamin Asbach wrote:
>>> Hi there,
>>>
>>> I've some problems with connecting to my containers via my public 
>>> domain from the host itself. I'm using bridged network by lxc 
>>> network. The setup looks like this
>>>
>>> remote -> domain.com -> host -> container1 (nginx) -> container2 (app)
>>>
>>> When I curl from a remote location this works quite fine:
>>>
>>>> curl https://sub.domain.com
>>>> <html></html>%
>>> But when I'm doing the same from the host itself:
>>>
>>>> curl https://sub.domain.com
>>>> curl: (7) Failed to connect to sub.domain.com port 443: Connection 
>>>> refused
>>> I'm a little bit confused why this happens. I though it might be 
>>> connected to iptables. But the rules look good for me:

<snip/>

>>> Might be the issue related to the bridged network or do you've any 
>>> ideas what's causing the problem?!
>>
>> Hi Benjamin, I'll give this a stab.
>>
>> Does the host have an address on the bridge?  To test, give it one.
>> If it works make sure to add iptables rules so the host only accepts
>> EST,REL traffic from the bridge guests (barbarians at the gates, etc).
>>
>> If you don't want the host to have a bridge address you'll have to set
>> up some other method such as NAT like you did for traffic coming in on
>> ens18.
>>
> 
> thanks for your reply! I checked that the adapter has an address:
> ip addr
> 2: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
> state UP group default qlen 1000
>      link/ether fe:06:96:f6:16:da brd ff:ff:ff:ff:ff:ff
>      inet 10.0.4.1/24 scope global lxdbr0
>         valid_lft forever preferred_lft forever
>      inet6 fe80::5c98:e8ff:fe13:66e3/64 scope link
>         valid_lft forever preferred_lft forever
> I tried to get some information what you've meant. But currently I'm a 
> little bit confused howto apply these ESTABLISHED and RELATED rules to 
> iptables. Do you mind if you can get a litte bit more detail in that?

Those are part of the "connection tracking" part of iptables.  Check out 
"man iptables-extensions" -> conntrack for all the details.  I don't 
know how much you know so I'll be basic.  If you already know this stuff 
skip down to the example rules.

WRT general traffic, packets can be in 1 of 4 states: INVALID, NEW, 
ESTABLISHED, or RELATED.  New packets create a stream.  If a NOT NEW 
packet arrives and is not part of any known stream it is INVALID and 
should be DROP'd (log if curious), otherwise it is ESTABLISHED as part 
of a stream.  A special type of NEW packet is RELATED: it's establishing 
a NEW connection but only as part of a pre-existing conversation such as 
FTP or ICMP.

As far as firewalling goes: keep everybody out of your host unless they 
absolutely MUST be there.  "Be there" includes answering responses to 
traffic you initiated and means you have to accept ESTABLISHED traffic 
or the connection dies.  Here is a bare firewall:

# our POLICY is that nothing gets in.
# watch every connection and only accept packets for established 
streams: that is response data to NEW streams created remotely because 
you asked for something: a web page, dns address, etc.
# note that having a default policy of DROP gets rid of INVALID packets

iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate EST,REL -j ACCEPT

#  or more specifically for a device
iptables -A INPUT -i lxdbr0 -m conntrack --ctstate EST,REL -j ACCEPT
iptables -A INPUT -i lxdbr0 -j DROP  ## get rid of INVALID and NEW

# are you a router?  same thing for FORWARDing
iptables -P FORWARD DROP
iptables -A FORWARD -m conntrack --ctstate EST,REL -j ACCEPT

# ok, I'm a nameserver so I have to accept udp and tcp on port 53
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m tcp --dport 53 -j 
ACCEPT
-A INPUT -i eth0 -p udp -m conntrack --ctstate NEW -m udp --dport 53 -j 
ACCEPT

You could also DROP OUTPUT traffic and filter all outgoing packets for 
even more control.

Anyway, those are some example rules and intro to connection tracking.

As to your current problem:

Do you have firewalls in the guests that might be blocking traffic from 
other devices on 10.4.0.0/24?

Try connecting to one of your guests using  lxc-attach and run tcpdump 
to make sure that your connection attempt is being seen.  Run tcpdump on 
your host and watch for outgoing and incoming traffic.  To not drown in 
data tell tcpdump what to show, e.g. tcpdump -i lxdbr0 port 80.  Use -nn 
to see IP and port number instead of names.