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
[email protected]
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

Attachment: 0xAD7427D8.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
lxc-users mailing list
[email protected]
http://lists.linuxcontainers.org/listinfo/lxc-users

Reply via email to