1

I need to configure a DHCP-enabled network (192.168.2.) on a physical layer where resides an already existing network (192.168.1.) with static IPs. I have a Debian 7 server with two interfaces (server and interfaces are all virtuals) and I want to set ip up as the gateway for my network. I used eth0 for routing packets to the original network (to access the internet gatewat at 192.168.1.5) and eth1 for handling traffic from/to my network.

ifconfig

eth0      Link encap:Ethernet  HWaddr 00:0c:29:d4:02:1b  
          inet addr:192.168.1.110  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fed4:21b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21668983 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10044848 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10931368249 (10.1 GiB)  TX bytes:2383839079 (2.2 GiB)

eth1      Link encap:Ethernet  HWaddr 00:0c:29:d4:02:25  
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fed4:225/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14113604 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11269734 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1871598524 (1.7 GiB)  TX bytes:10331981618 (9.6 GiB)

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:8158 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8158 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:629690 (614.9 KiB)  TX bytes:629690 (614.9 KiB)

route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.5     0.0.0.0         UG    0      0        0 eth0
localnet        *               255.255.255.0   U     0      0        0 eth0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

iptables -vL

Chain INPUT (policy ACCEPT 5603K packets, 822M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy DROP 138K packets, 8597K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  14M 9542M ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
 398K   27M ACCEPT     all  --  eth1   any     anywhere             anywhere            

Chain OUTPUT (policy ACCEPT 2915K packets, 1432M bytes)
 pkts bytes target     prot opt in     out     source               destination         

iptables -tnat -vL

Chain PREROUTING (policy ACCEPT 607K packets, 49M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 112K packets, 17M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 6893 packets, 977K bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain POSTROUTING (policy ACCEPT 2391 packets, 374K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 363K   24M MASQUERADE  all  --  any    eth0    anywhere             anywhere   

After that I enabled an authoritative DHCP server on eth1.

Now the problem: connections with the server are always working (I have a samba share and a MySQL server there) but sometimes (seems randomly) the clients (mainly Windows 7 or XP) fail to connect to the internet for a variable period of time. When in this condition I am able to ping to 192.168.1.110 but not to 192.168.1.5.

Addendum

The fact the FORWARD chain had dropped packets seems suspicious, so I temporarily disabled that filtering with:

iptables -A FORWARD -j ACCEPT

With this new rule in place everything works. I still need to clarify what's going on, though...

Addendum 2

These are the actual iptables rules:

iptables-save

# Generated by iptables-save v1.4.14 on Fri Jun 27 20:53:32 2014
*mangle
:PREROUTING ACCEPT [28129147:14012989399]
:INPUT ACCEPT [8479051:1218948772]
:FORWARD ACCEPT [19639349:12792010625]
:OUTPUT ACCEPT [4434912:3183821941]
:POSTROUTING ACCEPT [23940877:15968783924]
COMMIT
# Completed on Fri Jun 27 20:53:32 2014
# Generated by iptables-save v1.4.14 on Fri Jun 27 20:53:32 2014
*nat
:PREROUTING ACCEPT [931027:74896097]
:INPUT ACCEPT [153578:23398245]
:OUTPUT ACCEPT [9169:1292388]
:POSTROUTING ACCEPT [3186:492868]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Jun 27 20:53:32 2014
# Generated by iptables-save v1.4.14 on Fri Jun 27 20:53:32 2014
*filter
:INPUT ACCEPT [2415796:331288771]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1218435:1654003511]
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -j ACCEPT
COMMIT
# Completed on Fri Jun 27 20:53:32 2014
  • Running two IP subnets on the same physical lan isn't quite optimal.. I would implement a single subnet and configure a subset of the address space for DHCP and another subset for static IPs. Anyway, I wouldn't do the MASQUERADE here, except if you cannot configure 192.168.1.5 to do NAT for both networks. 192.168.1.5 would need a routing table entry for 192.168.2.0/24 network, and the routing table would tell that 192.168.1.110 is the gateway for that network. This way you don't get the extra NAT, which could be the problem here. – Tero Kilkanen Jun 26 '14 at 1:46
  • It is not my choice: the first subnet is not under my control, so I cannot modify the already existing IPs (and they are spread across all the address space) or reserve a subset for DHCP. – fetasail Jun 26 '14 at 19:29
0

To help you diagnose where the packets are flowing through iptables chains you might use the -j LOG parameter and eventually the --log-prefix "some text to easily identify log in kern.log or syslog " You might let the default Accept policy and add a deny all rule at the end of the FORWARD chain with logging enabled so that you can better understand what kind of packets are being Dropped.

You might have a look at this schematics http://www.linuxnetmag.com/share/issue9/iptables3.jpg , which show the basic flow of packets inside iptables chains.

It would be interesting to have the complete iptable rules you have defined to give a better answer.

  • Thanks for your answer: I updated the question including the actual rules. I do not understand your suggestion: actually the rules are working because of the last -A FORWARD -j ACCEPT rule. If I remove it (and I think I should) the remaining two rules in the FORWARD chain seen to be not enough because sometimes internet access on some clients is "detached". – fetasail Jun 27 '14 at 19:11
  • As explained in this post at the end of the text, you can use the LOG target to log into a file (usually kern.log of messages) packets that match your rule. So, try adding iptables -A FORWARD -j LOG --log-prefix "FORWARD : Might have been blocked!" before your rule iptables -A FORWARD -j ACCEPT so that every packet which should have been blocked will be logged. This might help you understand which packets are blocked... You can add other "LOG" rules so into other chains to understand the packet flow. – rebrec Jun 29 '14 at 8:10
  • The LOG rule confirmed that some arbitrary packet comes from eth0 but not from eth1. I was expecting to find every packet in both devices... either are virtually connected to the same network after all. – fetasail Jul 10 '14 at 6:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.