eth - NAT - Bridge - veth

eth - NAT - Bridge - veth

[Vijay Viswanathan]

Hi
I have a setup where
lxc ( container/light weight sandbox ) brings up veth and setsup IP as
192.168.10.2. and runs telnet server ( on port 2300 )

I created a bridge with IP 192.168.10.2 attaching the veth.

After the route setup, the host ( with eth1: 10.4.38.222 ) is able to
ping the veth ( 192.168.10.2 ) and vice versa.

Now how do I connect to the telnet server on 192.168.10.2: 2300 from
10.4.3x.xxx network ?

I guess I need some kind of NAT rules
I tried : http://www.pdxsys.com/articles/lxc/lxc2/ but in vain.



------- setup ----------------


# ifconfig from host:
br0       Link encap:Ethernet  HWaddr FE:26:4E:1E:96:58
          inet addr:192.168.10.1  Bcast:192.168.10.255  Mask:255.255.255.0
          inet6 addr: fe80::6c17:ebff:fe0b:4960/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:935 errors:0 dropped:0 overruns:0 frame:0
          TX packets:463 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:66496 (64.9 KiB)  TX bytes:39538 (38.6 KiB)

eth0      Link encap:Ethernet  HWaddr 00:00:DE:AD:BE:EF
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth1      Link encap:Ethernet  HWaddr 00:00:DE:AD:BE:EE
          inet addr:10.4.38.182  Bcast:10.4.39.255  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:134332 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1961 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:19183426 (18.2 MiB)  TX bytes:169630 (165.6 KiB)

eth1:0    Link encap:Ethernet  HWaddr 00:00:DE:AD:BE:EE
          inet addr:192.168.17.10  Bcast:192.168.17.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:756 (756.0 B)  TX bytes:756 (756.0 B)

veth2     Link encap:Ethernet  HWaddr FE:E5:84:6E:5F:58
          inet6 addr: fe80::fce5:84ff:fe6e:5f58/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:475 errors:0 dropped:0 overruns:0 frame:0
          TX packets:896 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:40254 (39.3 KiB)  TX bytes:59336 (57.9 KiB)

veth3     Link encap:Ethernet  HWaddr FE:26:4E:1E:96:58
          inet6 addr: fe80::fc26:4eff:fe1e:9658/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:441 errors:0 dropped:0 overruns:0 frame:0
          TX packets:893 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:37874 (36.9 KiB)  TX bytes:58770 (57.3 KiB)

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.4.39.254     0.0.0.0         UG    0      0        0 eth1
10.4.38.0       *               255.255.254.0   U     0      0        0 eth1
192.168.10.0    *               255.255.255.0   U     0      0        0 br0
192.168.17.0    *               255.255.255.0   U     0      0        0 eth1
# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
#

tried :

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.fe264e1e9658       no              veth2
                                                        veth3

also tried adding :

# brctl addif br0 eth1
# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0000deadbeee       no              eth1
                                                        veth2
                                                        veth3


Thanks.

Re: eth - NAT - Bridge - veth

[Pascal Hambourg]

Hello,

Vijay Viswanathan a écrit :
> I have a setup where
> lxc ( container/light weight sandbox ) brings up veth and setsup IP as
> 192.168.10.2. and runs telnet server ( on port 2300 )
> 
> I created a bridge with IP 192.168.10.2 attaching the veth.

Why ?
Note : the address on br0 is different in the output of ifconfig.
Is 192.168.10.2 the address of the container or the host ?

> After the route setup, the host ( with eth1: 10.4.38.222 )

Note : the address on eth1 is different in the output of ifconfig.

> is able to ping the veth ( 192.168.10.2 ) and vice versa.

Vice versa ? What do you mean exactly ? What commands do you run ?

> Now how do I connect to the telnet server on 192.168.10.2: 2300 from
> 10.4.3x.xxx network ?

Assuming the routing is properly set up on the network (i.e. hosts on
the network or the default router have a route to 192.168.10.0/24 with
gateway 10.4.38.182) and forwarding is enable on the host
(net.ipv4.ip_forward=1), just run :

$ telnet <container_address> 2300

> I guess I need some kind of NAT rules

Only as a last resort if you cannot setup proper routing on the network.

> also tried adding :
> 
> # brctl addif br0 eth1

If you add eth1 to the bridge, then you must :
- move the IP address from eth1 to br0,
- use an IP address in the external network subnet for the container.

Re: eth - NAT - Bridge - veth

[Vijay Viswanathan]

I cannot use the host network for container/veth IPs, so it looks like
I need a NAT.
some comments inline

On Fri, Jun 27, 2014 at 3:44 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Hello,
>
> Vijay Viswanathan a écrit :
>> I have a setup where
>> lxc ( container/light weight sandbox ) brings up veth and setsup IP as
>> 192.168.10.2. and runs telnet server ( on port 2300 )
>>
>> I created a bridge with IP 192.168.10.2 attaching the veth.
>
> Why ?
[VV]I specify that in the container conf. It will come up with a veth
and it will attach it to the given bridge. There is very little I can
do here.
[VV]I cannot have the container come up with the host network IP ( It
has to be some private network IP)
> Note : the address on br0 is different in the output of ifconfig.
> Is 192.168.10.2 the address of the container or the host ?
container ( with vethxx )
>
>> After the route setup, the host ( with eth1: 10.4.38.222 )
>
> Note : the address on eth1 is different in the output of ifconfig.
[VV] am sorry c
>
>> is able to ping the veth ( 192.168.10.2 ) and vice versa.
>
> Vice versa ? What do you mean exactly ? What commands do you run ?
>
[VV]just ping from container to host ping 10.4.38.222

>> Now how do I connect to the telnet server on 192.168.10.2: 2300 from
>> 10.4.3x.xxx network ?
>
> Assuming the routing is properly set up on the network (i.e. hosts on
> the network or the default router have a route to 192.168.10.0/24 with
> gateway 10.4.38.182) and forwarding is enable on the host
> (net.ipv4.ip_forward=1), just run :
>
> $ telnet <container_address> 2300
>
[VV] This is not an option in my design. Outside world knows only the
host IP and it should route the 2300 traffic to the server in
192.168.10.2: 2300

>> I guess I need some kind of NAT rules
>
> Only as a last resort if you cannot setup proper routing on the network.
>
>> also tried adding :
>>
>> # brctl addif br0 eth1
>
> If you add eth1 to the bridge, then you must :
> - move the IP address from eth1 to br0,
> - use an IP address in the external network subnet for the container.
[VV] That is not an option but I tried it anyways and it worked
earlier. Now I need to move forward with the container on a non host
network :(

Thanks.

Re: eth - NAT - Bridge - veth

[Pascal Hambourg]

Vijay Viswanathan a écrit :
> I cannot use the host network for container/veth IPs, so it looks like
> I need a NAT.

Indeed.

Enable IP forwarding on the host (sysctl net.ipv4.ip_forward=1).
Set default route in the container (seems to be set already).
Set port forwarding (DNAT) on the host to the container.

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 2300 \
  -j DNAT --to 192.168.10.2:2300

Optionally, set masquerading (SNAT) on the host for the containers.

iptables -t nat -A POSTROUTING -o eth1 -s 192.168.10.0/24 \
  -j MASQUERADE

Re: eth - NAT - Bridge - veth

[Vijay Viswanathan]

I did that but still not working. the telnet [telnet 10.4.38.182 2300]
command is stuck for a long time

# iptables -t nat --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             tcp
dpt:2300 to:192.168.10.2:2300

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  192.168.10.0/24      anywhere

also with -d 10.4.38.182
# iptables -t nat --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             10.4.38.182          tcp
dpt:2300 to:192.168.10.2:2300

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  192.168.10.0/24      anywhere

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.4.39.254     0.0.0.0         UG    0      0        0 eth1
10.4.38.0       *               255.255.254.0   U     0      0        0 eth1
192.168.10.0    *               255.255.255.0   U     0      0        0 br0

// Ping from host to veth is fine
# ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2): 56 data bytes
64 bytes from 192.168.10.2: seq=0 ttl=64 time=0.559 ms

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.fe5585cf0c11       no              veth2

On Fri, Jun 27, 2014 at 10:51 AM, Pascal Hambourg
<pascal@plouf.fr.eu.org> wrote:
> Vijay Viswanathan a écrit :
>> I cannot use the host network for container/veth IPs, so it looks like
>> I need a NAT.
>
> Indeed.
>
> Enable IP forwarding on the host (sysctl net.ipv4.ip_forward=1).
> Set default route in the container (seems to be set already).
> Set port forwarding (DNAT) on the host to the container.
>
> iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 2300 \
>   -j DNAT --to 192.168.10.2:2300
>
> Optionally, set masquerading (SNAT) on the host for the containers.
>
> iptables -t nat -A POSTROUTING -o eth1 -s 192.168.10.0/24 \
>   -j MASQUERADE
>

Re: eth - NAT - Bridge - veth

[Pascal Hambourg]

Vijay Viswanathan a écrit :
> I did that but still not working. the telnet [telnet 10.4.38.182 2300]
> command is stuck for a long time
> 
> # iptables -t nat --list

Please use iptables-save instead. The output is much easier to read.

> # route

Can you provide the output of the same commands run in the container ?
Can the container connect to or ping some external host ?

Re: eth - NAT - Bridge - veth

[Vijay Viswanathan]

good point.
The container is able to ping other machines in the network
# traceroute 10.4.38.222
traceroute to 10.4.38.222 (10.4.38.222), 30 hops max, 38 byte packets
 1  192.168.10.1 (192.168.10.1)  0.047 ms  0.023 ms  0.019 ms
 2  10.4.38.222 (10.4.38.222)  0.439 ms  0.393 ms  0.320 ms
#

also :
The container is able to ping the host

# traceroute 10.4.38.182
traceroute to 10.4.38.182 (10.4.38.182), 30 hops max, 38 byte packets
 1  10.4.38.182 (10.4.38.182)  0.052 ms  0.023 ms  0.018 ms

and vice versa ( from host to container ) :
# traceroute 192.168.10.2
traceroute to 192.168.10.2 (192.168.10.2), 30 hops max, 38 byte packets
 1  192.168.10.2 (192.168.10.2)  0.050 ms  0.032 ms  0.026 ms


From host --

# iptables-save
# Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
*nat
:PREROUTING ACCEPT [1:142]
:INPUT ACCEPT [1:142]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 10.4.38.182/32 -i eth1 -p tcp -m tcp --dport 2300 -j
DNAT --to-destination 192.168.10.2:2300
-A POSTROUTING -s 192.168.10.0/24 -o eth1 -j MASQUERADE
COMMIT
# Completed on Thu Jan  1 02:34:10 1970
# Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
*mangle
:PREROUTING ACCEPT [19518:3047480]
:INPUT ACCEPT [18424:2795220]
:FORWARD ACCEPT [476:70846]
:OUTPUT ACCEPT [3080:241144]
:POSTROUTING ACCEPT [3556:311990]
COMMIT
# Completed on Thu Jan  1 02:34:10 1970
# Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
*filter
:INPUT ACCEPT [60:3920]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [36:2555]
COMMIT
# Completed on Thu Jan  1 02:34:10 1970

From container -----------

# iptables-save
# Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
*nat
:PREROUTING ACCEPT [16:918]
:INPUT ACCEPT [16:918]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Thu Jan  1 02:35:19 1970
# Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
*mangle
:PREROUTING ACCEPT [72:4292]
:INPUT ACCEPT [72:4292]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [16:1012]
:POSTROUTING ACCEPT [16:1012]
COMMIT
# Completed on Thu Jan  1 02:35:19 1970
# Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
*filter
:INPUT ACCEPT [72:4292]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [16:1012]
COMMIT
# Completed on Thu Jan  1 02:35:19 1970



Thanks a lot

On Fri, Jun 27, 2014 at 12:18 PM, Pascal Hambourg
<pascal@plouf.fr.eu.org> wrote:
> Vijay Viswanathan a écrit :
>> I did that but still not working. the telnet [telnet 10.4.38.182 2300]
>> command is stuck for a long time
>>
>> # iptables -t nat --list
>
> Please use iptables-save instead. The output is much easier to read.
>
>> # route
>
> Can you provide the output of the same commands run in the container ?
> Can the container connect to or ping some external host ?

Re: eth - NAT - Bridge - veth

[Vijay Viswanathan]

adding -m state --state NEW,ESTABLISHED seems to do the trick.

iptables -t nat -A PREROUTING -i eth1 -p tcp -d 10.4.38.182 --dport
2300 -m state --state NEW,ESTABLISHED -j DN
AT --to 192.168.10.2:2300


Thanks a lot for guiding.

On Fri, Jun 27, 2014 at 1:08 PM, Vijay Viswanathan
<vijay.vishy@gmail.com> wrote:
> good point.
> The container is able to ping other machines in the network
> # traceroute 10.4.38.222
> traceroute to 10.4.38.222 (10.4.38.222), 30 hops max, 38 byte packets
>  1  192.168.10.1 (192.168.10.1)  0.047 ms  0.023 ms  0.019 ms
>  2  10.4.38.222 (10.4.38.222)  0.439 ms  0.393 ms  0.320 ms
> #
>
> also :
> The container is able to ping the host
>
> # traceroute 10.4.38.182
> traceroute to 10.4.38.182 (10.4.38.182), 30 hops max, 38 byte packets
>  1  10.4.38.182 (10.4.38.182)  0.052 ms  0.023 ms  0.018 ms
>
> and vice versa ( from host to container ) :
> # traceroute 192.168.10.2
> traceroute to 192.168.10.2 (192.168.10.2), 30 hops max, 38 byte packets
>  1  192.168.10.2 (192.168.10.2)  0.050 ms  0.032 ms  0.026 ms
>
>
> From host --
>
> # iptables-save
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
> *nat
> :PREROUTING ACCEPT [1:142]
> :INPUT ACCEPT [1:142]
> :OUTPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> -A PREROUTING -d 10.4.38.182/32 -i eth1 -p tcp -m tcp --dport 2300 -j
> DNAT --to-destination 192.168.10.2:2300
> -A POSTROUTING -s 192.168.10.0/24 -o eth1 -j MASQUERADE
> COMMIT
> # Completed on Thu Jan  1 02:34:10 1970
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
> *mangle
> :PREROUTING ACCEPT [19518:3047480]
> :INPUT ACCEPT [18424:2795220]
> :FORWARD ACCEPT [476:70846]
> :OUTPUT ACCEPT [3080:241144]
> :POSTROUTING ACCEPT [3556:311990]
> COMMIT
> # Completed on Thu Jan  1 02:34:10 1970
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
> *filter
> :INPUT ACCEPT [60:3920]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [36:2555]
> COMMIT
> # Completed on Thu Jan  1 02:34:10 1970
>
> From container -----------
>
> # iptables-save
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
> *nat
> :PREROUTING ACCEPT [16:918]
> :INPUT ACCEPT [16:918]
> :OUTPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> COMMIT
> # Completed on Thu Jan  1 02:35:19 1970
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
> *mangle
> :PREROUTING ACCEPT [72:4292]
> :INPUT ACCEPT [72:4292]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [16:1012]
> :POSTROUTING ACCEPT [16:1012]
> COMMIT
> # Completed on Thu Jan  1 02:35:19 1970
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
> *filter
> :INPUT ACCEPT [72:4292]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [16:1012]
> COMMIT
> # Completed on Thu Jan  1 02:35:19 1970
>
>
>
> Thanks a lot
>
> On Fri, Jun 27, 2014 at 12:18 PM, Pascal Hambourg
> <pascal@plouf.fr.eu.org> wrote:
>> Vijay Viswanathan a écrit :
>>> I did that but still not working. the telnet [telnet 10.4.38.182 2300]
>>> command is stuck for a long time
>>>
>>> # iptables -t nat --list
>>
>> Please use iptables-save instead. The output is much easier to read.
>>
>>> # route
>>
>> Can you provide the output of the same commands run in the container ?
>> Can the container connect to or ping some external host ?

Re: eth - NAT - Bridge - veth

[Neal Murphy]

On the host, does 'tcpdump -i any port 2300' reveal anything? You might even 
try the same on the container. At least you'd be able to see the packets at 
they flow through the system.


On Friday, June 27, 2014 04:08:57 PM Vijay Viswanathan wrote:
> good point.
> The container is able to ping other machines in the network
> # traceroute 10.4.38.222
> traceroute to 10.4.38.222 (10.4.38.222), 30 hops max, 38 byte packets
>  1  192.168.10.1 (192.168.10.1)  0.047 ms  0.023 ms  0.019 ms
>  2  10.4.38.222 (10.4.38.222)  0.439 ms  0.393 ms  0.320 ms
> #
> 
> also :
> The container is able to ping the host
> 
> # traceroute 10.4.38.182
> traceroute to 10.4.38.182 (10.4.38.182), 30 hops max, 38 byte packets
>  1  10.4.38.182 (10.4.38.182)  0.052 ms  0.023 ms  0.018 ms
> 
> and vice versa ( from host to container ) :
> # traceroute 192.168.10.2
> traceroute to 192.168.10.2 (192.168.10.2), 30 hops max, 38 byte packets
>  1  192.168.10.2 (192.168.10.2)  0.050 ms  0.032 ms  0.026 ms
> 
> >From host --
> 
> # iptables-save
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
> *nat
> 
> :PREROUTING ACCEPT [1:142]
> :INPUT ACCEPT [1:142]
> :OUTPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> 
> -A PREROUTING -d 10.4.38.182/32 -i eth1 -p tcp -m tcp --dport 2300 -j
> DNAT --to-destination 192.168.10.2:2300
> -A POSTROUTING -s 192.168.10.0/24 -o eth1 -j MASQUERADE
> COMMIT
> # Completed on Thu Jan  1 02:34:10 1970
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
> *mangle
> 
> :PREROUTING ACCEPT [19518:3047480]
> :INPUT ACCEPT [18424:2795220]
> :FORWARD ACCEPT [476:70846]
> :OUTPUT ACCEPT [3080:241144]
> :POSTROUTING ACCEPT [3556:311990]
> 
> COMMIT
> # Completed on Thu Jan  1 02:34:10 1970
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:34:10 1970
> *filter
> 
> :INPUT ACCEPT [60:3920]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [36:2555]
> 
> COMMIT
> # Completed on Thu Jan  1 02:34:10 1970
> 
> >From container -----------
> 
> # iptables-save
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
> *nat
> 
> :PREROUTING ACCEPT [16:918]
> :INPUT ACCEPT [16:918]
> :OUTPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> 
> COMMIT
> # Completed on Thu Jan  1 02:35:19 1970
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
> *mangle
> 
> :PREROUTING ACCEPT [72:4292]
> :INPUT ACCEPT [72:4292]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [16:1012]
> :POSTROUTING ACCEPT [16:1012]
> 
> COMMIT
> # Completed on Thu Jan  1 02:35:19 1970
> # Generated by iptables-save v1.4.21 on Thu Jan  1 02:35:19 1970
> *filter
> 
> :INPUT ACCEPT [72:4292]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [16:1012]
> 
> COMMIT
> # Completed on Thu Jan  1 02:35:19 1970
> 
> 
> 
> Thanks a lot
> 
> On Fri, Jun 27, 2014 at 12:18 PM, Pascal Hambourg
> 
> <pascal@plouf.fr.eu.org> wrote:
> > Vijay Viswanathan a écrit :
> >> I did that but still not working. the telnet [telnet 10.4.38.182 2300]
> >> command is stuck for a long time
> >> 
> >> # iptables -t nat --list
> > 
> > Please use iptables-save instead. The output is much easier to read.
> > 
> >> # route
> > 
> > Can you provide the output of the same commands run in the container ?
> > Can the container connect to or ping some external host ?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eth - NAT - Bridge - veth

[Pascal Hambourg]

Vijay Viswanathan a écrit :
> adding -m state --state NEW,ESTABLISHED seems to do the trick.
> 
> iptables -t nat -A PREROUTING -i eth1 -p tcp -d 10.4.38.182 --dport
> 2300 -m state --state NEW,ESTABLISHED -j DNAT --to 192.168.10.2:2300

Not in any way. The chains of the nat table see only packets in the NEW
state so this match is completely superflous. Besides, normal TCP
packets have the NEW or ESTABLISHED state.

Re: eth - NAT - Bridge - veth

[Vijay Viswanathan]

you are right. No idea what made it work :)

one thing different from your original instruction was my sysctl
net.ipv4.ip_forward=1 didnt work couple of times it said 'unknown key'
3rd try it did not complain but after some tests I saw the forwarding
was not set and I had to set it by writing 1 into /proc... ip_foward

I will post it once I find out, but so far good.

Thx.

On Fri, Jun 27, 2014 at 2:38 PM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Vijay Viswanathan a écrit :
>> adding -m state --state NEW,ESTABLISHED seems to do the trick.
>>
>> iptables -t nat -A PREROUTING -i eth1 -p tcp -d 10.4.38.182 --dport
>> 2300 -m state --state NEW,ESTABLISHED -j DNAT --to 192.168.10.2:2300
>
> Not in any way. The chains of the nat table see only packets in the NEW
> state so this match is completely superflous. Besides, normal TCP
> packets have the NEW or ESTABLISHED state.