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

Mon Sep 4 01:19:06 UTC 2017

On 2017-09-03 02:52, Mike Wright wrote:
> 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.
> 
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

Thanks for the explanation! I think the problem on my site was that I 
did not realize that when I do a request a) it's output traffic and b) 
it's passed through loopback interface.

I created an OUTPUT rule which solves the problem I had.

Thanks
Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xAD7427D8.asc
Type: application/pgp-keys
Size: 3061 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170904/29e1ca68/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170904/29e1ca68/attachment-0001.sig>