0

I had this configuration before, and it used to work well, but now I got a new server and I can't setup it to share the internet connection from ppp0. I'm on Debian testing.

The client connects directly on eth0 through a dhcp server, and it can get an IP just fine. The problem seems only to appear when I set this rule:

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Just after that, the client won't be able to receive an IP from the server anymore. Here's the configuration files:

Interfaces configuration:

iface eth0 inet static
    address 192.168.0.1
    netmask 255.255.255.0

The /etc/dhcp/dhcpd.conf file:

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 192.168.0.0 netmask 255.255.255.0 {
   option routers 192.168.0.1;
   option domain-name "onix";
   range 192.168.0.2 192.168.0.10;
   option domain-name-servers 201.10.120.2, 201.10.128.2;
   option ip-forwarding on;
}

The connection script:

#!/bin/bash

ifdown eth0
ifup eth0
/etc/init.d/isc-dhcp-server stop
/etc/init.d/isc-dhcp-server start

iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp0 -o eth0 -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A FORWARD -i ppp0 -o ppp0 -j REJECT

echo 1 > /proc/sys/net/ipv4/ip_forward

Edit: After the problem appears, these are the client's syslog:

Aug 21 04:52:13 amendoa dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Aug 21 04:52:20 amendoa dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Aug 21 04:52:41 amendoa dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Aug 21 04:52:44 amendoa dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Aug 21 04:52:51 amendoa dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13

And the server's one:

Aug 21 04:52:13 onix dhcpd: DHCPREQUEST for 192.168.0.2 from 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:13 onix dhcpd: DHCPACK on 192.168.0.2 to 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:20 onix dhcpd: DHCPREQUEST for 192.168.0.2 from 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:20 onix dhcpd: DHCPACK on 192.168.0.2 to 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:41 onix dhcpd: DHCPDISCOVER from 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:41 onix dhcpd: DHCPOFFER on 192.168.0.2 to 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:44 onix dhcpd: DHCPDISCOVER from 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:44 onix dhcpd: DHCPOFFER on 192.168.0.2 to 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:51 onix dhcpd: DHCPDISCOVER from 00:16:36:96:2b:15 (amendoa) via eth0
Aug 21 04:52:51 onix dhcpd: DHCPOFFER on 192.168.0.2 to 00:16:36:96:2b:15 (amendoa) via eth0

Client tcpdump:

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:32:10.848029 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:16.000175 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:30.004579 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:37.005508 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:49.007886 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:56.000168 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300

Server tcpdump:

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:32:10.533386 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:10.536878 ARP, Request who-has 192.168.0.2 tell onix.local, length 28
17:32:11.000641 IP onix.local.bootps > 192.168.0.2.bootpc: BOOTP/DHCP, Reply, length 300
17:32:11.535919 ARP, Request who-has 192.168.0.2 tell onix.local, length 28
17:32:12.535882 ARP, Request who-has 192.168.0.2 tell onix.local, length 28
17:32:15.685847 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:15.686038 IP onix.local.bootps > 192.168.0.2.bootpc: BOOTP/DHCP, Reply, length 300
17:32:36.692468 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:36.692678 IP onix.local.bootps > 192.168.0.2.bootpc: BOOTP/DHCP, Reply, length 300
17:32:48.695611 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:48.695863 IP onix.local.bootps > 192.168.0.2.bootpc: BOOTP/DHCP, Reply, length 300
17:32:55.688296 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:16:36:96:2b:15 (oui Unknown), length 300
17:32:55.688546 IP onix.local.bootps > 192.168.0.2.bootpc: BOOTP/DHCP, Reply, length 300
womble
  • 96,255
  • 29
  • 175
  • 230
vmassuchetto
  • 111
  • 4
  • As I said, this configuration "was working before". The new server I'm working has the following ethernet card: 13:00.0 Ethernet controller: Atheros Communications AR8152 v2.0 Fast Ethernet (rev c1) After testing things again and again experiencing this odd network behavior, I didn't realize that my kernel version was really old: 2.6.32. This kernel version has a [Debian bug](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610474) that describes exactly what was happening. All I had to do was upgrade to 3.0.0, that has a fixed driver for AR8152. Everything works fine now. I'm really sorry for – vmassuchetto Aug 22 '11 at 11:24

1 Answers1

0

I'll bet that this line:

/sbin/ifconfig eth0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.1

isn't doing you any favours (I seriously doubt that's actually your broadcast address, and we stopped having to specify them manually years ago -- for that matter, why are you even manually scripting your interface configuration?).

I seriously doubt that the MASQUERADE rule you identify as being the problem is actually the source of the issue -- it shouldn't have any effect on the DHCP server's desire to serve addresses (although a misconfigured PPP connection could cause issues, it should cause those issues regardless of whether you're masquerading).

Without knowing what the DHCP server is actually doing with the packets it receives, it's hard to diagnose what's actually going on. Relevant syslog entries will be enlightening; at worst, an strace of the DHCP server will show whether the packets are getting to the DHCP server and (roughly) what it's doing with the responses.

womble
  • 96,255
  • 29
  • 175
  • 230
  • Replaced the tcpdump thing with the syslog entries. Also, using the interfaces file for setting eth0 configuration gives me the same results. Thanks for the help. – vmassuchetto Aug 21 '11 at 08:19
  • Removing the broadcast entry from the dhcpd.conf and interfaces file also gives me the same results. – vmassuchetto Aug 21 '11 at 08:35