Custom Search

Monday, July 28, 2014

Howto connect two network namespaces using veth pairs

1)
Add two namespaces "ns1" and "ns2"
#sudo ip netns add ns1
#sudo ip netns add ns2

2)
List all namespaces
#sudo ip netns list

3)
List all interfaces in the global namespace
#ifconfig  -a
OR
#ifconfig -a | less

4)
Create veth interface pairs "tap1" and "tap2" in the global namespace
#sudo ip link add tap1 type veth peer name tap2

5)
List all interfaces in the global namespace
#ifconfig  -a
OR
#ifconfig -a | less

* At this point the interfaces "tap1" and "tap2" doesn't have IP associated with it.

6)
Move "tap1" and "tap2" interfaces from global namespace to the "ns1"and "ns2" namespace.

* Move "tap1" interface to "ns1" namespace
#sudo ip link set tap1 netns ns1

* Move "tap2" interface to "ns2" namespace
#sudo ip link set tap2 netns ns2

* At this point run "#ifconfig -a" in global namespace an you would not able to see the "tap1" and "tap2" interfaces there.

7)
Goto namespace "ns1" and "ns2" and run "#ifconfig -a" to see the interface "tap1" and "tap2"
#sudo ip netns exec ns1 ifconfig -a
#sudo ip netns exec ns2 ifconfig -a

8)
Assign IP addess to "tap1" and "tap2"
#sudo ip netns exec ns1 ip addr add 10.1.1.4/16 dev tap1
#sudo ip netns exec ns2 ip addr add 10.1.1.5/16 dev tap2

9)
Bring up the link/interface "tap1" and "tap2"
#sudo ip netns exec ns1 ip link set tap1 up
#sudo ip netns exec ns2 ip link set tap2 up

10)
Check the IP address of the interface "tap1" and "tap2"
#sudo ip netns exec ns1 ifconfig -a
#sudo ip netns exec ns2 ifconfig -a

11)
Ping from ns1 to ns2
#sudo ip netns exec ns1 ping 10.1.1.5

12)
Ping from ns2 to ns1
#sudo ip netns exec ns2 ping 10.1.1.4

13)
http://www.opencloudblog.com/?p=66




Friday, July 25, 2014

How to confirm that SNAT and MASQUERADE are using conntrack table to replace the destination IP address of the reply packet

How to confirm that SNAT and MASQUERADE are using conntrack table to replace the destination IP address of the reply packet

http://superuser.com/questions/255705/internal-working-of-rules-in-forward-chain-for-nat

http://conntrack-tools.netfilter.org/conntrack.html

1)
This MASQUERADE target rule performs Source NAT: It replaces the source address of exiting packets from 192.168.1.xxx to your public IP address, while at the same time recording the details of the NAT in the router's conntrack (connection tracking) table.

Because the details of the NAT is recorded, reply packets from the Internet will be checked against that table. If the reply matches a conntrack entry, the packet will experience an 'inverse NAT' (my term), i.e., replacing the destination address (remember, this is a reply!) with the original sender's address (192.168.1.xxx)

2)
Install conntrack

#sudo apt-get install conntrack
http://conntrack-tools.netfilter.org/conntrack.html

3)
Some conntrack commands

a)
Flush conntrack table

#sudo conntrack -F

b)
Dump source NAT connection

#sudo conntrack -L --src-nat

c)
Display a real-time event log

#sudo conntrack -F

d)
List connection tacking table

#sudo conntrack -L

4)
How to see entries in the connection tacking table for the NAT
a)
Add the SNAT target rule

#sudo iptables -t nat -A POSTROUTING -p icmp --dst 173.194.127.147 -j SNAT --to-source 10.0.2.15
OR
Add the MASQUERADE target rule
#sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

b)
ping to the destination IP

#sudo ip netns exec myns1 ping 173.194.127.147

c)
Dump source NAT connection

#sudo conntrack -L --src-nat

5)
How to confirm that, SNAT and MASQUERADE are using conntrack table to replace the destination IP address of the reply packet


a)
ping to the destination IP

#sudo ip netns exec myns1 ping 173.194.127.147

b)
Flush the conntrack table

#sudo conntrack -F
* Run this command continuously

c)
Capture the packet from the interface that come before the Nated interface

#sudo tshark -i veth0 icmp

* Here you can see that reply packets for some request packets are missing.
* See attached sreenshot. There we can't see the reply packets for the request packets 16 and 17.




Thursday, July 24, 2014

Howto Network gateway allow and deny packets

Howto gateway allow and deny packets

Gateway interface only allow certain packets to go through it, that is, if the routing table can't find the network which match the destination IP address of the packet.

Example:
* Your gateway interface is veth1

* IP of your gateway interface is 10.1.1.3

* Here the gateway interface veth1 only allow the packets which has destination IP address don't not match/belongs the networks added/defined in the routing table.

* So we need to add SNAT or MASQUERADE rule in the NAT table and change source IP of the packets and get the reply/ACK for the packets we sent.

* When you ping or wget/curl from our namespace "myns1" to different network (eg:ping 173.194.127.147 / www.google.com), the packets will go through the default gateway 10.1.1.3. But we will not get the response/reply back, if the routing table can't find the network for the source IP address of the packets.

http://fosshelp.blogspot.in/2014/07/introduction-to-network-namespace-and.html


Wednesday, July 23, 2014

How to remove an interface from a Network Namespace

To remove an interface from a Network namespace you must send it back to the global namespace.

Syntax:
#ip netns exec ip link set netns 1

Example:
#ip netns exec myname-space ip link set veth1 netns 1

Introduction to Network Namespace, Default Gateway and ARP Table with VirtualBox Virtual Machine

A)
Setup the network namespace

1)
Add a namespace
#sudo ip netns add myns1

2)
List all namespaces
#ip netns list

3)
Execute commands in a namespace
#sudo ip netns exec myns1

4)
Check all the interfaces and their IP in the namespace "myns1"
#sudo ip netns exec myns1 ifconfig -a
#sudo ip netns exec myns1 ip link list

5)
Create veth interface pairs (veth0 and veth1) in global namespace (VirtualBox VM)
#sudo ip link add veth0 type veth peer name veth1

6)
List and check veth pairs created in the global namespace (VirtualBox VM)
#ip link list
OR
#ifconfig -a

* At this point the interface veth0 and "veth1" don't have any IP,So don't belongs to any network.

7)
If you want to connect the global namespace (VirtualBox VM) to the "myns1" namespace, you will need to move one of the veth interfaces to the "myns1" namespace using this command.
#sudo ip link set veth1 netns myns1

8)
Check namespace "myns1", there you can see the moved interface "veth1".
#sudo ip netns exec myns1 ip link
OR
#sudo ip netns exec myns1 ifconfig -a

* At this point the interface "veth1" doesn't have any IP, So doesn't belongs to any network.
* If you run "#ip link list" or "#ifconfig -a" in global namespace, you can't see the "veth1" interface, since it moved to namespace "myns1".

9)
List routing table in the namespace "myns1"
#sudo ip netns exec myns1 route -n
OR
#sudo ip netns exec myns1 ip route list

* At this point, this will be empty.

10)
Assign an IP "10.1.1.2" to "veth1" interface OR Add the interface "veth1" to a network "10.1.1.2/24 or 10.1.1.x".
#sudo ip netns exec myns1 ifconfig veth1 10.1.1.2/24 up

11)
List routing table in the namespace "myns1"
#sudo ip netns exec myns1 route -n
OR
#sudo ip netns exec myns1 ip route list

* At this point you can see the network "10.1.1.2/24 or 10.1.1.x" with interface "veth1" in the routing table.

#sudo ip netns exec myns1 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth1

12)
List routing table in the global namespace (VirtualBox VM)
#route -n
OR
#ip route list

* You can see the "veth0" not there in the routing table. So we need to add it.

13)
Assign an IP "10.1.1.3" to "veth0" interface OR Add the interface "veth0" to the same network "10.1.1.2/24 or 10.1.1.x" of "veth1".
#sudo ifconfig veth0 10.1.1.3/24 up

* Note: "veth0" and "veth1" should be in same network "10.1.1.2/24 or 10.1.1.x".

14)
List routing table in the global namespace (VirtualBox VM)
#route -n
OR
#ip route list

* At this point you can see the network "10.1.1.2/24 or 10.1.1.x" with interface "veth0" in the routing table.

#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth0
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

15)
Test IPs
* Ping to interface "veth0" in the global namespace from global namespace
#ping 10.1.1.3

*Ping to interface "veth1" in the "myns1" namespace from global namespace
#ping 10.1.1.2

* Ping to interface "veth0" in the global namespace from "myns1" namespace
#sudo ip netns exec myns1 ping 10.1.1.3

B)
Testing

1)
Start tshark to caputre the packets from the "veth1" inferface in the network namespace "myns1"
#sudo ip netns exec myns1 tshark -i veth1 icmp

2)
Start tshark to caputre the packets from the "veth0" interface in the global network namespace
#sudo tshark -i veth0 icmp

3)
Check Routing Table in the network namespace "myns1"
#sudo ip netns exec myns1 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth1

* Note: This routing table doesn't have default gateway. So we can't ping to other network from this namespace "myns1". We can only ping to the network 10.1.1.x.

4)
Check ARP Table in the network namespace "myns1"
#sudo ip netns exec myns1 arp -a
? (10.1.1.3) at 52:14:8c:a0:4f:ea [ether] on veth1

* See it has only one entry that map the IP:10.1.1.3 to MAC:52:14:8c:a0:4f:ea
* Actually this entry is for the interface "veth1" (10.1.1.3) in the global namespace.

4,a)
You can delete that entry from ARP table like
#sudo ip netns exec myns1 arp -d 10.1.1.3

4,b)
Check ARP table again
#sudo ip netns exec myns1 arp -a
? (10.1.1.3) at on veth1

* Note the , that means IP:10.1.1.3 doen't map to any MAC.

4,c)
Ping to 10.1.1.3 to add/update the ARP table from the IP:10.1.1.3

#sudo ip netns exec myns1 ping 10.1.1.3

4,d)
Again check the ARP Table in the network namespace "myns1"

#sudo ip netns exec myns1 arp -a
? (10.1.1.3) at 52:14:8c:a0:4f:ea [ether] on veth1

* Now you can see the IP amd MAC map, IP:10.1.1.3 to MAC:52:14:8c:a0:4f:ea

5)
Find the IP and MAC of interface veth0 and veth1


5,a)
IP and MAC of interface veth0 in the global namespace
(VirtualBox VM)
#ifconfig -a veth0
veth0     Link encap:Ethernet  HWaddr 52:14:8c:a0:4f:ea 
          inet addr:10.1.1.3  Bcast:10.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5014:8cff:fea0:4fea/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1158 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1848 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:64991 (64.9 KB)  TX bytes:150257 (150.2 KB)

* IP : 10.1.1.3
* MAC : 52:14:8c:a0:4f:ea

5,b)
IP and MAC of interface veth1 in the namespace "myns1"

#sudo ip netns exec myns1 ifconfig -a veth1
veth1     Link encap:Ethernet  HWaddr 8e:a6:de:48:bf:a2 
          inet addr:10.1.1.2  Bcast:10.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::8ca6:deff:fe48:bfa2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1848 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1158 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:150257 (150.2 KB)  TX bytes:64991 (64.9 KB)

* IP : 10.1.1.2
* MAC : 8e:a6:de:48:bf:a2

6)
ping to veth0 (10.1.1.3) in the global network namespace from network
namespace "myns1" and check the packets flowing through the interface "veth0" and "veth1".
#sudo ip netns exec myns1 ping 10.1.1.3
PING 10.1.1.3 (10.1.1.3) 56(84) bytes of data.
64 bytes from 10.1.1.3: icmp_seq=1 ttl=64 time=0.062 ms

* Ping working

6,a)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1"

#sudo ip netns exec myns1 tshark -i veth1
icmp
1   0.000000     10.1.1.2 -> 10.1.1.3     ICMP 98 Echo (ping) request  id=0x680d, seq=1/256, ttl=64
2   0.000039     10.1.1.3 -> 10.1.1.2     ICMP 98 Echo (ping) reply    id=0x680d, seq=1/256, ttl=64 (request in 1)

* request abd reply are working well
* Here you can see that packet flowing from 10.1.1.2 -> 10.1.1.3

6,b)
Capture the Packets flowing through the interface "veth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i veth0
icmp
1   0.000000     10.1.1.2 -> 10.1.1.3     ICMP 98 Echo (ping) request  id=0x680d, seq=1/256, ttl=64
2   0.000031     10.1.1.3 -> 10.1.1.2     ICMP 98 Echo (ping) reply    id=0x680d, seq=1/256, ttl=64 (request in 1)

* request abd reply are working well
* Here you can see that packet flowing from 10.1.1.2 -> 10.1.1.3

7)
Ping to an unknown IP (10.1.1.6) in the same network "10.1.1.x" from namespace "myns1"

#sudo ip netns exec myns1 ping 10.1.1.6
PING 10.1.1.6 (10.1.1.6) 56(84) bytes of data.
From 10.1.1.2 icmp_seq=1 Destination Host Unreachable

* Ping not works. Destination Host Unreachable

7,a)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1
"
#sudo ip netns exec myns1 tshark -i veth1
icmp
1   0.000000 8e:a6:de:48:bf:a2 -> Broadcast    ARP 42 Who has 10.1.1.6?  Tell 10.1.1.2
2   0.998262 8e:a6:de:48:bf:a2 -> Broadcast    ARP 42 Who has 10.1.1.6?  Tell 10.1.1.2

Note:
* Here "8e:a6:de:48:bf:a2" is the MAC of interface "veth1" (10.1.1.2) in the namespace "myns1".
* Here you can see that packet flowing from 8e:a6:de:48:bf:a2 to-> Broadcast

7,b)
Capture the Packets flowing through the interface "veth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i veth0
icmp
1   0.000000 8e:a6:de:48:bf:a2 -> Broadcast    ARP 42 Who has 10.1.1.6?  Tell 10.1.1.2
2   0.998262 8e:a6:de:48:bf:a2 -> Broadcast    ARP 42 Who has 10.1.1.6?  Tell 10.1.1.2

* Here you can see that packet flowing from 8e:a6:de:48:bf:a2 to-> Broadcast

7,c)
Check ARP Table in the network namespace "myns1"

#sudo ip netns exec myns1 arp -a
? (10.1.1.3) at 52:14:8c:a0:4f:ea [ether] on veth1
? (10.1.1.6) at on veth1

* You can see the entry for the IP:10.1.1.6, but MAC is . That means could not able to find a machine with IP:10.1.1.6 in the network 10.1.1.x.

8)
Ping to an IP:192.168.56.101 in the different network "192.168.56.x" from namespace "myns1"

#sudo ip netns exec myns1 ping 192.168.56.101
connect: Network is unreachable

OR

#sudo ip netns exec myns1 ping www.google.com
ping: unknown host www.google.com

8,a)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1"

#sudo ip netns exec myns1 tshark -i veth1
icmp

* Packets will not come here

8,b)
Capture the Packets flowing through the interface "veth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i veth0
icmp

* Packets will not come here

8,c)
Check Routing Table in the network namespace "myns1"

#sudo ip netns exec myns1 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth1

* Here we can't find any gateway.
* Here we need to add a default gateway to flow packets which are not destined for the network 10.1.1.x to outside.
* Note: We can use the interface "veth0" (10.1.1.3) in the global namespace as the gateway for the namespace "myns1".
* Note, "veth0" and "veth1" are veth pairs.

8,d)
Add a default gateway to flow packets which are not destined for the network 10.1.1.x to outside.

#sudo ip netns exec myns1 route add default gw 10.1.1.3 veth1


8,e)
Check Routing Table in the network namespace "myns1"

#sudo ip netns exec myns1 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.1.3        0.0.0.0         UG    0      0        0 veth1
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth1


8,f )
Howto gateway allow and deny packets
http://fosshelp.blogspot.in/2014/07/howto-network-gateway-allow-and-deny.html

9)
Again Ping to the IP:192.168.56.101 in the different network "192.168.56.x" from namespace "myns1" after adding the default gateway

#sudo ip netns exec myns1 ping 192.168.56.101
PING 192.168.56.101 (192.168.56.101) 56(84) bytes of data.
64 bytes from 192.168.56.101: icmp_seq=1 ttl=64 time=0.063 ms

* Ping works. That means the network "192.168.56.x" is reachable form the namespace "myns1"
* Note: The network "192.168.56.x"mis defined in the routing in the global namespace.

9,a)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1"

#sudo ip netns exec myns1 tshark -i veth1
icmp
1   0.000000     10.1.1.2 -> 192.168.56.101 ICMP 98 Echo (ping) request  id=0x7076, seq=1/256, ttl=64
1   2   0.000041 192.168.56.101 -> 10.1.1.2     ICMP 98 Echo (ping) reply    id=0x7076, seq=1/256, ttl=64 (request in 1)

* Here you can see that packet flowing from 10.1.1.2 to-> 192.168.56.101

* Here we can see request and reply packets
* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2 .

9,b)
Capture the Packets flowing through the interface "veth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i veth0
icmp
1   0.000000     10.1.1.2 -> 192.168.56.101 ICMP 98 Echo (ping) request  id=0x7076, seq=1/256, ttl=64
1   2   0.000033 192.168.56.101 -> 10.1.1.2     ICMP 98 Echo (ping) reply    id=0x7076, seq=1/256, ttl=64 (request in 1)

* Here you can see that packet flowing from 10.1.1.2 -> 192.168.56.101

* Here we can see request and reply packets
* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2.

9,c)
Check Routing Table in the global namespace. Routing table in the VirtualBox VM.

#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth0
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Note:
* Here i am using VirtualBox VM to test this.
* Here the network 10.0.2.x is VirtualBox NAT network.
* Here the network 10.1.1.x is the network I created for the namespace "myns1".
* Here the network 192.168.56.x is the HostOnly Network of VirtualBox.
* Here the gateway IP:10.0.2.2 belongs to the VirtualBox NAT network 10.0.2.x.
* Here 192.168.56.101 is the IP of this VirtualBox VM.
* Here the routing table will redirect the packets destined:192.168.56.101 and sourced:10.1.1.2 to network 192.168.56.x

10)
Ping to the IP:11.1.1.5 in the different network "11.1.1..x" from namespace "myns1" after adding the default gateway


* Note: the network 11.1.1.x doesn't exist. 
 
#sudo ip netns exec myns1 ping 11.1.1.5
PING 11.1.1.5 (11.1.1.5) 56(84) bytes of data <== Hung

* Ping not works.
* Note, Here the network 11.1.1.x doen't exist in the routing table in the global namespace. So the packets will forwarded to the default gateway "10.0.2.2" defined in the routing table in the global namespace. Please check the routing table defined in the global namespace.

10,a)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1"

#sudo ip netns exec myns1 tshark -i veth1
icmp
1   0.000000     10.1.1.2 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x734a, seq=1/256, ttl=64
2   1.008958     10.1.1.2 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x734a, seq=2/512, ttl=64


* See, we can see only request packets, no response/reply packets. That means response/reply packets are not flowing to this interface "veth0", somewhere reply packets got dropped.

* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2.

10,b)
Capture the Packets flowing through the interface "veth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i veth0
icmp
1   0.000000     10.1.1.2 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x734a, seq=1/256, ttl=64
2   1.008957     10.1.1.2 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x734a, seq=2/512, ttl=64



* See, we can see only request packets, no response/reply packets. That means response/reply packets are not flowing to this interface "veth0", somewhere reply packets got dropped.

* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2.

10,c)
Capture the Packets flowing through the interface "eth0" in the global namespace (VirtualBox VM).

#sudo tshark -i eth0
icmp
1   0.000000     10.1.1.2 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x734a, seq=1/256, ttl=63
2   1.008950     10.1.1.2 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x734a, seq=2/512, ttl=63

* Here "eth0" is the interface where default gateway is connected. Please check the routing table in the global namespace.


* You can see that our packets are flowing through this "eth0" interface, that means the routing table in the global namespace forwarding the packets to default gateway "10.0.2.2", because the destination IP:11.1.1.5 of the packet doesn't belongs to any networks defined in the routing table in the global namespace. Please check the routing table in the global namespace.


* See, we can see only request packets, no response/reply packets. That means response/reply packets are not flowing to this interface "veth0", somewhere reply packets got dropped.

* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2.

10,d)
Capture the Packets flowing through the interface "wlan0" in the Host Machine (My laptop).

#sudo tshark -i wlan0 icmp 

1   1.000145 192.168.0.131 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x2008, seq=132/33792, ttl=62
2   1.999461 192.168.0.131 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x2008, seq=133/34048, ttl=62
3   2.999875 192.168.0.131 -> 11.1.1.5     ICMP 98 Echo (ping) request  id=0x2008, seq=134/34304, ttl=62

* Note: "wlan0" interface is connected to INTERNET via WIFI 
* Here 192.168.0.131 is the IP of wlan0 interface

* See, we can see only request packets, no response/reply packets. That means response/reply packets are not flowing to this interface "wlan0", somewhere reply packets got dropped in the INTERNET.

* IMP Note: Here Source IP of the Packet got changed from 10.1.1.2 to 192.168.0.131, that means, we are doing SNAT or MASQUERADE before pushing the packets to the "wlan0" interface. I think VirtualBox doing this SNAT or MASQUERADE.

11)
Find the IP of the www.google.com and Ping to that IP from namespace "myns1"
 
after adding the default gateway

IP of the www.google.com is 173.194.127.147

#sudo ip netns exec myns1 ping 173.194.127.147
PING 173.194.127.147 (173.194.127.147) 56(84) bytes of data.

* Ping not works.
* Note, Here the network 173.194.127.x doen't exist in the routing table in the global namespace. So the packets will forwarded to the default gateway "10.0.2.2" defined in the routing table in the global namespace.

11,a)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1"

#sudo ip netns exec myns1 tshark -i veth1
icmp
1   0.000000     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x744f, seq=1/256, ttl=64
2   1.007237     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x744f, seq=2/512, ttl=64


* See, we can see only request packets, no response/reply packets. That means response/reply packets are not flowing to this interface "veth1", somewhere reply packets got dropped.

* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2. 

11,b)
Capture the Packets flowing through the interface "veth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i veth0
icmp
1   0.000000     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x744f, seq=1/256, ttl=64
2   1.007330     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x744f, seq=2/512, ttl=64


* See, we can see only request packets, no response/reply packets. That means response/reply packets are not flowing to this interface "veth0", somewhere reply packets got dropped.
  
* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2. 

11,c)
Capture the Packets flowing through the interface "eth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i eth0
icmp
1   0.000000     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x744f, seq=1/256, ttl=63
2   0.190104 RealtekU_12:35:02 -> Broadcast    ARP 60 Who has 10.1.1.2?  Tell 10.0.2.2
3   1.007366     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x744f, seq=2/512, ttl=63
4   1.648765 RealtekU_12:35:02 -> Broadcast    ARP 60 Who has 10.1.1.2?  Tell 10.0.2.2

* Here "eth0" is the interface where default gateway is connected. Please check the routing table in the global namespace.


* You can see that our packets are reaching at this "eth0" interface, that means the routing table in the global namespace forwarding the packets to default gateway "10.0.2.2", because the destination IP:173.194.127.147 doesn't belongs to any networks defined in the routing table in the global namespace. Please check the routing table in the global namespace.


* See, we can see only request packets, no response/reply packets. That means response/reply packets are not flowing to this interface "eth0", somewhere reply packets got dropped.

* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2.

11,d)
Capture the Packets flowing through the interface "wlan0" in the Host Machine (My laptop).

#sudo tshark -i wlan0 icmp
1   0.000000 192.168.0.131 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x2133, seq=23/5888, ttl=62
2   0.094715 173.194.127.147 -> 192.168.0.131 ICMP 98 Echo (ping) reply    id=0x2133, seq=23/5888, ttl=53 (request in 1)
3   1.000054 192.168.0.131 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x2133, seq=24/6144, ttl=62
4   1.091640 173.194.127.147 -> 192.168.0.131 ICMP 98 Echo (ping) reply    id=0x2133, seq=24/6144, ttl=53 (request in 3)


* Note: "wlan0" interface is connected to INTERNET via WIFI 
* Here 192.168.0.131 is the IP of wlan0 interface

* See, we can see both request and response packets. That means the IP:173.194.127.147 is reachable in the INTERNET.

* IMP Note: Here Source IP of the Packet got changed from 10.1.1.2 to 192.168.0.131, that means, we are doing SNAT or MASQUERADE before pushing the packets to the "wlan0" interface. I think VirtualBox doing this SNAT or MASQUERADE.

* IMP Note: Destination IP of the reply packet is 192.168.0.131, because in request packet source IP was 192.168.0.131. I already motioned that VirtualBox did this SNAT or MASQUERADE in the request packet, so again the VirtualBox will do the de-SNAT or de-MASQUERADE and change destination IP of the reply packet form 192.168.0.131 to 10.1.1.2 before pushing the packet to the "eth0" interface in the VirtualBox VM.But here the VirtualBox can't push the reply packet to eth0 interface, since the destination IP of the reply packet is 10.1.1.2 and IP of the eth0 interface is 10.0.2.15 (different network).

* Solution for this issue is add SNAT or MASQUERADE NAT iptables rule in the VirtualBox VM and change the source IP address of the request packet to 10.0.2.15 (IP of eth0 interface) before pushing to the eth0 interface in the VirtualBox VM, so later when reply packets come, VirtualBox can de-SNAT or de-MASQUERADE reply packet and change destination IP from 192.168.0.131 to 10.0.2.15 and push the to eth0 (10.0.2.15) interface. Then our SNAT or MASQUERADE iptables rules in the VirtualBox VM again de-SNAT or de-MASQUERADE reply packet and change destination IP from 10.0.2.15 to 10.1.1.2 and route to "veth1" interface  (network 10.1.1.x) in the VirtualBox VM. from there reply packet will reach to interface "veth0" (10.1.1.2) in the namespace "myns1".

11,e)
Add MASQUERADE rule to POSTROUTING chain of the NAT table for the interface "eth0" (in the VirtualBox VM) and test the ping again from the namespace "myns1" to 173.194.127.147 (www.google.com)


a)
Check rules in the POSTROUTING chain of the NAT table in the VirtualBox VM

#sudo iptables -t nat -L POSTROUTING -nv

b)
Add MASQUERADE target rule in the POSTROUTING chain of the NAT table for the interface "eth0" (in VirtualBox VM).

#sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

* Note: I haven't specified the protocol "-p tcp" here, So it will allow all including ICMP (Ping), or you can add "-p icmp" if you want to test only the Ping.

c)
Check rules in the POSTROUTING chain of the NAT table in the VirtualBox VM

#sudo iptables -t nat -L POSTROUTING -nv
Chain POSTROUTING (policy ACCEPT 1 packets, 328 bytes)
pkts bytes target     prot opt in     out     source               destination 
1    84 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0 <===

d)
Ping to 173.194.127.147 (www.google.com) from the namespace "myns1" in the VirtualBox VM.

#sudo ip netns exec myns1 ping 173.194.127.147
PING 173.194.127.147 (173.194.127.147) 56(84) bytes of data.
64 bytes from 173.194.127.147: icmp_seq=1 ttl=61 time=108 ms
64 bytes from 173.194.127.147: icmp_seq=2 ttl=61 time=111 ms

* Ping works here

e)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1"

#sudo ip netns exec myns1 tshark -i veth1 icmp
1   0.000000     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x332a, seq=1/256, ttl=64
2   0.108731 173.194.127.147 -> 10.1.1.2     ICMP 98 Echo (ping) reply    id=0x332a, seq=1/256, ttl=61 (request in 1)

* See request and reply packets are flowing through "veth1" interface.
* We don't need any NAT here, since for namespace "myns1" the interface "veth1" (10.1.1.3) in the global namespace act as a gateway interface.

f)
Capture the Packets flowing through the interface "veth0" in the global namespace (VirtualBox VM).

#sudo tshark -i veth0 icmp
1   0.000000     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x332a, seq=1/256, ttl=64
2   0.108696 173.194.127.147 -> 10.1.1.2     ICMP 98 Echo (ping) reply    id=0x332a, seq=1/256, ttl=61 (request in 1)

* See request and reply packets are flowing through "veth0" interface.
* Packets should flow through this interface "veth0" in the namespace "myns1" to reach the gateway interface "veth1" in the global namespace, since "veth0" and "veth1" are veth pairs. 

g)
Capture the Packets flowing through the interface "eth0" in the global namespace (VirtualBox VM).

#sudo tshark -i eth0 icmp
1   0.000000    10.0.2.15 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x332a, seq=1/256, ttl=63
2   0.108550 173.194.127.147 -> 10.0.2.15    ICMP 98 Echo (ping) reply    id=0x332a, seq=1/256, ttl=62 (request in 1)

* See request and reply packets are flowing through "eth0" interface.
* Note source IP address of the packet is changed here from 10.1.1.2 to 10.0.2.15 by our custom MASQUERADE target rule in the POSTROUTING chain of the NAT table. This conversion is required because the network of the interface is 10.0.2.x and source IP of the packet is 10.1.1.2 and reply packet will not pass through this interface because in reply packet destination IP addess will be the source IP address of the request Packet.

h)
Capture the Packets flowing through the interface "wlan0" in the Host Machine (My laptop).

#sudo tshark -i wlan0 icmp
1   0.000000 192.168.0.131 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x332a, seq=1/256, ttl=62
2   0.106184 173.194.127.147 -> 192.168.0.131 ICMP 98 Echo (ping) reply    id=0x332a, seq=1/256, ttl=53 (request in 1)

* See request and reply packets are flowing through "wlan0" interface.
* Note: Source IP address of the request packet is again changed from 10.0.2.15 to 192.168.0.131. This NAT is done by the VIrtualBox and we can't see that NAT rule.

i)
Routing table from namespace "myns1"
#sudo ip netns exec myns1 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.1.3        0.0.0.0         UG    0      0        0 veth1
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth1

j)
Routing table from global namespace
#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth0
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

11,f)
Delete the MASQUERADE target rule in the POSTROUTING chain of the NAT table for the interface "eth0" (in the VirtualBox VM) and add SNAT target rule in the POSTROUTING chain of the NAT table and test the ping again from the namespace "myns1" to 173.194.127.147 (www.google.com)


a)
Delete MASQUERADE target rule in the POSTROUTING chain of the NAT table

#sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

b)
Check rules in the POSTROUTING chain of the NAT table in the VirtualBox VM

#sudo iptables -t nat -L POSTROUTING -nv

c)
Add SNAT target rule in the POSTROUTING chain of the NAT table for the interface "eth0" (in VirtualBox VM).

#sudo iptables -t nat -A POSTROUTING -p icmp --dst 173.194.127.147 -j SNAT --to-source 10.0.2.15

* See, here I specified "-p icmp" so we can test only ping. We can change it to "-p tcp" to allow tcp protocol or remove it to allow all protocols

d)
Check rules in the POSTROUTING chain of the NAT table in the VirtualBox VM

#sudo iptables -t nat -L POSTROUTING -nv
Chain POSTROUTING (policy ACCEPT 1 packets, 328 bytes)
pkts bytes target     prot opt in     out     source               destination 
1    84 SNAT       icmp --  *      *       0.0.0.0/0            173.194.127.147      to:10.0.2.15

e)
Lsit all Tables and its chains and rules in the VirtualBox VM

#sudo iptables-save
# Generated by iptables-save v1.4.21 on Tue Jul 22 01:10:34 2014
*raw
:PREROUTING ACCEPT [171973:15026995]
:OUTPUT ACCEPT [128875:25991146]
COMMIT
# Completed on Tue Jul 22 01:10:34 2014
# Generated by iptables-save v1.4.21 on Tue Jul 22 01:10:34 2014
*nat
:PREROUTING ACCEPT [2:660]
:INPUT ACCEPT [1:576]
:OUTPUT ACCEPT [1:328]
:POSTROUTING ACCEPT [1:328]
-A PREROUTING -j LOG
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A POSTROUTING -d 173.194.127.147/32 -p icmp -j SNAT --to-source 10.0.2.15
COMMIT
# Completed on Tue Jul 22 01:10:34 2014
# Generated by iptables-save v1.4.21 on Tue Jul 22 01:10:34 2014
*mangle
:PREROUTING ACCEPT [193485:16689911]
:INPUT ACCEPT [158616:13775245]
:FORWARD ACCEPT [34861:2913076]
:OUTPUT ACCEPT [145297:30083538]
:POSTROUTING ACCEPT [180927:33061426]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Tue Jul 22 01:10:34 2014
# Generated by iptables-save v1.4.21 on Tue Jul 22 01:10:34 2014
*filter
:INPUT ACCEPT [158618:13775349]
:FORWARD ACCEPT [34861:2913076]
:OUTPUT ACCEPT [145290:30083718]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
COMMIT
# Completed on Tue Jul 22 01:10:34 2014

f)
Ping to 173.194.127.147 (www.google.com) from the namespace "myns1" in the VirtualBox VM.

#sudo ip netns exec myns1 ping 173.194.127.147
PING 173.194.127.147 (173.194.127.147) 56(84) bytes of data.
64 bytes from 173.194.127.147: icmp_seq=1 ttl=61 time=96.2 ms
64 bytes from 173.194.127.147: icmp_seq=2 ttl=61 time=102 ms

* Ping works here

g)
Capture the Packets flowing through the interface "veth0" in the global namespace (VirtualBox VM).

#sudo tshark -i veth0 icmp
1   0.000000     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x3e3d, seq=1/256, ttl=64
1   2   0.096169 173.194.127.147 -> 10.1.1.2     ICMP 98 Echo (ping) reply    id=0x3e3d, seq=1/256, ttl=61 (request in 1)

* See request and reply packets are flowing through "veth0" interface.

h)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1"

#sudo ip netns exec myns1 tshark -i veth1 icmp
1   0.000000     10.1.1.2 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x3e3d, seq=1/256, ttl=64
2   0.096202 173.194.127.147 -> 10.1.1.2     ICMP 98 Echo (ping) reply    id=0x3e3d, seq=1/256, ttl=61 (request in 1)

* See request and reply packets are flowing through "veth1" interface.

i)
Capture the Packets flowing through the interface "eth0" in the global namespace (VirtualBox VM).

#sudo tshark -i eth0 icmp
1   0.000000    10.0.2.15 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x3e3d, seq=1/256, ttl=63
2   0.096041 173.194.127.147 -> 10.0.2.15    ICMP 98 Echo (ping) reply    id=0x3e3d, seq=1/256, ttl=62 (request in 1)

* See request and reply packets are flowing through "eth0" interface.
* Note source IP address of the packet is changed here from 10.1.1.2 to 10.0.2.15 by our custom SNAT target rule in the POSTROUTING chain of the NAT table. This conversion is required because the network of the interface is 10.0.2.x and source IP of the packet is 10.1.1.2 and reply packet will not pass through this interface because in reply packet destination IP addess will be the source IP address of the request Packet.

j)
Capture the Packets flowing through the interface "wlan0" in the Host Machine (My laptop).

#sudo tshark -i wlan0 icmp
0.000000 192.168.0.131 -> 173.194.127.147 ICMP 98 Echo (ping) request  id=0x3e3d, seq=1/256, ttl=62
0.096050 173.194.127.147 -> 192.168.0.131 ICMP 98 Echo (ping) reply    id=0x3e3d, seq=1/256, ttl=53 (request in 1)

* See request and reply packets are flowing through "wlan0" interface.
* Note: Source IP address of the request packet is again changed from 10.0.2.15 to 192.168.0.131. This NAT is done by the VIrtualBox and we can't see that NAT rule.

12)
Ping to www.google.com from namespace "myns1"
after adding the default gateway
 
#sudo ip netns exec myns1 ping www.google.com
ping: unknown host www.google.com

12,a)
Capture the Packets flowing through the interface "veth1" in the namespace "myns1"

#sudo ip netns exec myns1 tshark -i veth1
icmp
1   0.000000     10.1.1.2 -> 10.0.2.3     DNS 74 Standard query 0xb814  A www.google.com
2   5.004542     10.1.1.2 -> 10.0.2.3     DNS 74 Standard query 0xb814  A www.google.com
3   5.015108 8e:a6:de:48:bf:a2 -> 52:14:8c:a0:4f:ea ARP 42 Who has 10.1.1.3?  Tell 10.1.1.2
4   5.015479 52:14:8c:a0:4f:ea -> 8e:a6:de:48:bf:a2 ARP 42 10.1.1.3 is at 52:14:8c:a0:4f:ea

* Note: Here packets are flowing from 10.1.1.2 to-> 10.0.2.3
* Here "10.0.2.3" is the IP of VirtualBox DNS server.

* Note, Source IP of the request packet not changed, still it showing original source IP:10.1.1.2. 

12,b)
Capture the Packets flowing through the interface "veth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i veth0
icmp
1   0.000000     10.1.1.2 -> 10.0.2.3     DNS 74 Standard query 0xb814  A www.google.com
2   5.004539     10.1.1.2 -> 10.0.2.3     DNS 74 Standard query 0xb814  A www.google.com
3   5.015098 8e:a6:de:48:bf:a2 -> 52:14:8c:a0:4f:ea ARP 42 Who has 10.1.1.3?  Tell 10.1.1.2
4   5.015449 52:14:8c:a0:4f:ea -> 8e:a6:de:48:bf:a2 ARP 42 10.1.1.3 is at 52:14:8c:a0:4f:ea

12,c)
Capture the Packets flowing through the interface "eth0" in the global namespace
(VirtualBox VM).
#sudo tshark -i eth0
icmp
1   0.000000     10.1.1.2 -> 10.0.2.3     DNS 74 Standard query 0xb814  A www.google.com
2   0.002024 RealtekU_12:35:02 -> Broadcast    ARP 60 Who has 10.1.1.2?  Tell 10.0.2.2
3   5.004501     10.1.1.2 -> 10.0.2.3     DNS 74 Standard query 0xb814  A www.google.com
4   5.008109 RealtekU_12:35:02 -> Broadcast    ARP 60 Who has 10.1.1.2?  Tell 10.0.2.2

13)
Ping to www.google.com from global namespace
in the VirtualBox VM
 

#ping www.google.com
PING www.google.com (173.194.127.242) 56(84) bytes of data.
64 bytes from 173.194.127.242: icmp_seq=1 ttl=63 time=93.6 ms
64 bytes from 173.194.127.242: icmp_seq=2 ttl=63 time=128 ms

* Ping works

13,a)
Capture the Packets flowing through the interface "eth0" in the global namespace (VirtualBox VM).
#sudo tshark -i eth0 icmp

1   0.000000    10.0.2.15 -> 173.194.127.242 ICMP 98 Echo (ping) request  id=0x3fb6, seq=1/256, ttl=64
2   0.093585 173.194.127.242 -> 10.0.2.15    ICMP 98 Echo (ping) reply    id=0x3fb6, seq=1/256, ttl=63 (request in 1)
 

13,b)
Capture the Packets flowing through the interface "wlan0" in the Host Machine (My laptop).
#sudo tshark -i wlan0 icmp

1   0.000000 192.168.0.131 -> 173.194.127.242 ICMP 98 Echo (ping) request  id=0x3fb6, seq=1/256, ttl=63
2   0.092806 173.194.127.242 -> 192.168.0.131 ICMP 98 Echo (ping) reply    id=0x3fb6, seq=1/256, ttl=53 (request in 1)





Tuesday, July 22, 2014

iptables example DNAT SNAT and MASQUERADE with network namespace

1)
Create a network namespace and run a simple webserver inside it and make it accessible from global namespace. I am using a VirtualBox Virtual Machine (Ubuntu 14.04) to run this test.


a)
Add a namespace

#sudo ip netns add myns1

b)
List all namespaces

#ip netns list

c)
Execute commands in a namespace

#sudo ip netns exec myns1

d)
Check all the interfaces and their IP in the namespace "myns1"

#sudo ip netns exec myns1 ifconfig -a
#sudo ip netns exec myns1 ip link list


e)
Create veth interface pairs (veth0 and veth1) in global namespace

#ip link add veth0 type veth peer name veth1

f)
List and check veth pairs created in the global namespace

#ip link list
OR
#ifconfig -a


* At this point the interface veth0 and "veth1" don't have any IP,So don't belongs to any network.

g)
If you want to connect the global namespace to the "myns1" namespace, you will need to move one of the veth interfaces to the "myns1" namespace using this command.

#sudo ip link set veth1 netns myns1

h)
Check namespace "myns1", there you can see the moved interface "veth1".

#sudo ip netns exec myns1 ip link
OR
#sudo ip netns exec myns1 ifconfig -a


* At this point the interface "veth1" doesn't have any IP, So doesn't belongs to any network.
* If you run "#ip link list" or "#ifconfig -a" in global namespace, you can't see the "veth1" interface, since it moved to namespace "myns1".

i)
List routing table in the namespace "myns1"

#sudo ip netns exec myns1 route -n
OR
#sudo ip netns exec myns1 ip route list


* At this point, this will be empty.

j)
Assign an IP "10.1.1.2" to "veth1" interface OR Add the interface "veth1" to a network "10.1.1.2/24 or 10.1.1.x".

#sudo ip netns exec myns1 ifconfig veth1 10.1.1.2/24 up

k)
List routing table in the namespace "myns1"

#sudo ip netns exec myns1 route -n
OR
#sudo ip netns exec myns1 ip route list


* At this point you can see the network "10.1.1.2/24 or 10.1.1.x" with interface "veth1" in the routing table.

l)
List routing table in the global namespace

#route -n
OR
#ip route list


* You can see the "veth0" not there in the routing table. So we need to add it.

m)
Assign an IP "10.1.1.3" to "veth0" interface OR Add the interface "veth0" to the same network "10.1.1.2/24 or 10.1.1.x" of "veth1".

#sudo ifconfig veth0 10.1.1.3/24 up

* Note: "veth0" and "veth1" should be in same network "10.1.1.2/24 or 10.1.1.x".

n)
List routing table in the global namespace

#route -n
OR
#ip route list


* At this point you can see the network "10.1.1.2/24 or 10.1.1.x" with interface "veth0" in the routing table.

o)
Test IPs

* Ping to interface "veth0" in the global namespace from global namespace
#ping 10.1.1.3

*Ping to interface "veth1" in the "myns1" namespace from global namespace
#ping 10.1.1.2

* Ping to interface "veth0" in the global namespace from "myns1" namespace
#sudo ip netns exec myns1 ping 10.1.1.3

p)
Run a simple webserver inside the namespace "myns1"

#vim index.html
Hello World
#sudo ip netns exec myns1 netcat -l 80 < index.html

q)
Access webserver running in the namespace "myns1" from global namespace in the Virtual Machine

#wget http://10.1.1.2:80
OR
#curl http://10.1.1.2:80


2)
Add a rule with
"DNAT" target in the "PREROUTING" chain of NAT iptables table in the global namespace.

* The DNAT target is used to do Destination Network Address Translation, which means that it is used to rewrite the Destination IP address of a packet. If a packet is matched, and this (DNAT) is the target of the rule, the packet, and all subsequent packets in the same stream will be translated, and then routed on to the correct device, host or network.
http://www.iptables.info/en/iptables-targets-and-jumps.html#DNATTARGET

a)
List all rules in the PREROUTING chain of NAT table

#sudo iptables -t nat -L PREROUTING -nv

b)
Check this before adding the rule with
"DNAT" target in the Virtual Machine. curl from your host machine (Ubuntu 13.10).
#curl http://192.168.56.101:8083
curl: (7) Failed to connect to 192.168.56.101 port 8083: Connection refused

c)
Add a rule with port DNAT target to PREROUTING chain of NAT table in the Virtual Machine

#sudo iptables -t nat -A PREROUTING -p tcp -d 192.168.56.101 --dport 8083 -j DNAT --to-destination 10.1.1.2:80
OR
Specify in-interface and remove destination IP
#sudo iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8083 -j DNAT --to-destination 10.1.1.2:80

* IMP: you should specify destination port with destination IP, like  --to-destination 10.1.1.2:80
* Replace -A with -D to remove this rule
* We can't test ping, since we specified "-p tcp" in the rule. If you want test ping, please remove "-p tcp" from the rule or replace "-p tcp" with "-p icmp".

d)
List all rules in the PREROUTING chain of NAT table

#sudo iptables -t nat -L PREROUTING -nv

e)
Just check this.(Optional)

#sudo netstat -ntlp | grep 80
tcp6       0      0 :::80                   :::*                    LISTEN      2084/apache2

f)
curl from your host machine
(Ubuntu 13.10) after adding the rule with DNAT target in the Virtual Machine
#curl http://192.168.56.101:8083

Here curl will not work.
http://www.iptables.info/en/iptables-targets-and-jumps.html#DNATTARGET

f,a)
How to debug.

Goto the Virtual Machine and inspect the "veth1" interface in the namespace "myns1" using tshark and check the SYN packet.
In the output below, you can see that SYN signals are comming to "veth1" interface (10.1.1.2) from 192.168.56.1 (This means DNAT is working), but ACK signals not going back (you can see TCP Retransmission).

#sudo ip netns exec myns1 tshark -i veth1 -f "not port 22"

1   0.000000 192.168.56.1 -> 10.1.1.2     TCP 74 41491 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=40849675 TSecr=0 WS=128
1   2   0.996335 192.168.56.1 -> 10.1.1.2     TCP 74 [TCP Retransmission] 41491 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=40849925 TSecr=0 WS=128
2   3   3.000209 192.168.56.1 -> 10.1.1.2     TCP 74 [TCP Retransmission] 41491 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=40850426 TSecr=0 WS=128
3   4   5.000510 52:14:8c:a0:4f:ea -> 8e:a6:de:48:bf:a2 ARP 42 Who has 10.1.1.2?  Tell 10.1.1.3
4   5   5.000586 8e:a6:de:48:bf:a2 -> 52:14:8c:a0:4f:ea ARP 42 10.1.1.2 is at 8e:a6:de:48:bf:a2

g)
Add a rule with SNAT target in POSTROUTING chain of NAT table in the Virtual Machine

#sudo iptables -t nat -A POSTROUTING -p tcp --dst 10.1.1.2 --dport 80 -j SNAT --to-source 10.1.1.3
OR
Add a rule with MASQUERADE target (for out interface veth0) in POSTROUTING chain of NAT table in the Virtual Machine

#sudo iptables -t nat -A POSTROUTING -p TCP -o veth0 -j MASQUERADE --to-ports 80
*This will auto SNAT the packets going to the interface veth0 or network 10.1.1.x 

http://www.iptables.info/en/iptables-targets-and-jumps.html#MASQUERADETARGET

* Note: Here i am used the match "-p tcp --dst 10.1.1.2 --dport 80", because DNAT in the PREROUTING chain already changed the destination IP and port on the packet.
* Replace -A with -D to remove this rule
* We can't test ping, since we specified "-p tcp" in the rule. If you want test ping, please remove "-p tcp" from the rule or replace "-p tcp" with "-p icmp". 

h)
curl from your host machine
(Ubuntu 13.10) after adding the rule with DNAT target in the Virtual Machine
#curl http://192.168.56.101:8083

This will work.
http://www.iptables.info/en/iptables-targets-and-jumps.html#DNATTARGET

h,a)
How to debug.

Goto the Virtual Machine and inspect the "veth1" interface in the namespace "myns1" using tshark and check the SYN packet.
In the output below, you can see that http SYN signals are comming to "veth1" interface (10.1.1.2) from 10.1.1.3 (line-1) and http ACK signal going back from 10.1.1.2 to 10.1.1.3 (line-2) and final http ACK signal from 10.1.1.3 to 10.1.1.2 (line-3). Yoy can also see the HTTP GET request from 10.1.1.3 to 10.1.1.2 (line-5).

#sudo ip netns exec myns1 tshark -i veth1 -f "not port 22"

1   0.000000     10.1.1.3 -> 10.1.1.2     TCP 74 41538 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=41139563 TSecr=0 WS=128
2   0.000154     10.1.1.2 -> 10.1.1.3     TCP 74 http > 41538 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=40860573 TSecr=41139563 WS=128
3   0.000458     10.1.1.3 -> 10.1.1.2     TCP 66 41538 > http [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=41139563 TSecr=40860573
4   0.001053     10.1.1.2 -> 10.1.1.3     HTTP 79 Continuation or non-HTTP traffic
5   0.001376     10.1.1.3 -> 10.1.1.2     HTTP 149 GET / HTTP/1.1
6   0.001398     10.1.1.3 -> 10.1.1.2     TCP 66 41538 > http [ACK] Seq=84 Ack=14 Win=29312 Len=0 TSval=41139564 TSecr=40860573
7   0.001548     10.1.1.2 -> 10.1.1.3     TCP 66 http > 41538 [ACK] Seq=14 Ack=84 Win=29056 Len=0 TSval=40860573 TSecr=41139563
8   0.007233     10.1.1.2 -> 10.1.1.3     TCP 66 http > 41538 [FIN, ACK] Seq=14 Ack=84 Win=29056 Len=0 TSval=40860575 TSecr=41139564
9   0.007576     10.1.1.3 -> 10.1.1.2     TCP 66 41538 > http [FIN, ACK] Seq=84 Ack=15 Win=29312 Len=0 TSval=41139565 TSecr=40860575

i)
curl from Virtual Machine or please where we added this iptables rules (firewall machine).


#curl http://192.168.56.101:8083
curl: (7) Failed to connect to 192.168.56.101 port 8083: Connection refused

* This will not work.
http://www.iptables.info/en/iptables-targets-and-jumps.html#DNATTARGET

j)
Add a rule with DNAT target to OUTPUT chain

http://www.iptables.info/en/iptables-targets-and-jumps.html#DNATTARGET

#sudo iptables -t nat -A OUTPUT --dst 192.168.56.101 -p tcp --dport 8083 -j DNAT --to-destination 10.1.1.2:80

* IMP: you should specify destination port with destination IP, like  --to-destination 10.1.1.2:80

* We can't test ping, since we specified "-p tcp" in the rule. If you want test ping, please remove "-p tcp" from the rule or replace "-p tcp" with "-p icmp". 

* Please check the attached figure, you can see that the packets originated from local process/system are passing through OUTPUT and then POSTROUTING chain. So here, for locally generated packets, OUTPUT chain will do DNAT and then POSTROUTING chain will do SNAT.








k)
curl from Virtual Machine or please where we added this iptables rules (firewall machine).


#curl http://192.168.56.101:8083


* This will work.
http://www.iptables.info/en/iptables-targets-and-jumps.html#DNATTARGET

k,a)
How to debug.

Goto the Virtual Machine and inspect the "veth1" interface in the namespace "myns1" using tshark and check the SYN packet.
In the output below, you can see that http SYN signals are comming to "veth1" interface (10.1.1.2) from 10.1.1.3 (line-1) and http ACK signal going back from 10.1.1.2 to 10.1.1.3 (line-2) and final http ACK signal from 10.1.1.3 to 10.1.1.2 (line-3). Yoy can also see the HTTP GET request from 10.1.1.3 to 10.1.1.2 (line-7).

#sudo ip netns exec myns1 tshark -i veth1 -f "not port 22"

1   0.000000     10.1.1.3 -> 10.1.1.2     TCP 74 37848 > http [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=43099616 TSecr=0 WS=128
2   0.000033     10.1.1.2 -> 10.1.1.3     TCP 74 http > 37848 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=43099616 TSecr=43099616 WS=128
3   0.000051     10.1.1.3 -> 10.1.1.2     TCP 66 37848 > http [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=43099616 TSecr=43099616
4   0.000131     10.1.1.2 -> 10.1.1.3     HTTP 79 Continuation or non-HTTP traffic
5   0.000144     10.1.1.3 -> 10.1.1.2     TCP 66 37848 > http [ACK] Seq=1 Ack=14 Win=43776 Len=0 TSval=43099616 TSecr=43099616
6   0.000158     10.1.1.2 -> 10.1.1.3     TCP 66 http > 37848 [FIN, ACK] Seq=14 Ack=1 Win=29056 Len=0 TSval=43099616 TSecr=43099616
7   0.000208     10.1.1.3 -> 10.1.1.2     HTTP 149 GET / HTTP/1.1
8   0.000218     10.1.1.2 -> 10.1.1.3     TCP 66 http > 37848 [ACK] Seq=15 Ack=84 Win=29056 Len=0 TSval=43099616 TSecr=43099616
9   0.002479     10.1.1.3 -> 10.1.1.2     TCP 66 37848 > http [FIN, ACK] Seq=84 Ack=15 Win=43776 Len=0 TSval=43099617 TSecr=43099616
10   0.002490     10.1.1.2 -> 10.1.1.3     TCP 66 http > 37848 [ACK] Seq=15 Ack=85 Win=29056 Len=0 TSval=43099617 TSecr=43099617