Connecting Linux to Bezeq WOW/ADSL

Connecting Linux to Bezeq WOW/ADSL

This page is intended to document the steps I went through to connect my Linux box to the internet via Bezeq's WOW/ADSL service using Urbis as an ISP. It likely contains errors and omissions, so, as always, caveat emptor, especially when it is free... How well this description works for you can depend on details such as your physical location within Israel, the exact model of ADSL modem you have, and your ISP. Also, I do not intend to provide any support, and this description carries no warrantee explicit or implied.

Currently there is only one internet broadband solution for home users in Israel: Bezeq's WOW/ADSL service. Unfortunately, Bezeq only supports Windows clients, and does not support Linux users. In addition, their technical support does not divulge any information on the configuration of their networks or hardware to make it easier for Linux users to deduce the right software and configuration for WOW/ADSL.

After I had figured out how to connect my Linux machine to the Bezeq WOW/ADSL, I found a very good HOWTO-ADSL-BEZEQ, which I wish I had known about before I had embarked on my own reverse engineering project.

Fortunately, I have both Windows and Linux machines at home, and with some tools such as sniffit, I was able to figure out how to get my Mandrake 8.1 system to talk to WOW/ADSL. My ISP is currently Urbis, but I could choose any one of a number of other providers. The ADSL-BEZEQ-HOWTO has a more complete list of providers. To my uncertain knowledge, Urbis provides the cheapest rates for unlimited ADSL in Israel.

I do know that Bezeq uses different ADSL modems in different parts of the country. I have heard that they use Alcatel ADSL modems in the center (Tel Aviv, Herzliyya, etc.), and Orckit modems in the north. I also know that they use at least two different models of Orckit modems, and that I have an ATUR3 modem.

Home Environment

A brief discussion of my home network. I want my Linux machine to act as a firewall and router for my home network. It has two ethernet cards, eth0 and eth1. Eth0 is connected to my internal network and eth1 is connected to the Orckit ADSL modem. I want to share printers and drives between machines within the network, and I want the internal machines to be able to reach the outside through the firewall. However, I do not want the outside to reach through the firewall to my internal machines.

I have a printer and a scanner connected to my Windows machine, and I want the printer to be accessible from Linux. I would also like to share disk space between machines, because it is convenient, and because I can then automatically mirror my important content onto two separate disks on two separate machines (paranoia).

I will have three subnets at home: 10.0.0.x will be the subnet connected to the ADSL modem, and 192.168.x will be the external, tunnelled subnet to my ISP. Both of these will be considered external, or unsafe and should be outside the firewall. 172.16.1.x will be my internal subnet.

Windows WOW/ADSL

I got the WOW/ADSL service as part of the trial, before ISPs had ADSL accounts. When they installed the system, they installed both the modem and some custom software which with Internet Explorer enabled you to create a connection and choose an ISP. At some point after the trial period you would use this software to create a connection and choose an ISP for this connection and you paid per-minute charges on the connection. About this time, some ISPs also started providing WOW/ADSL services and you could open an account with that ISP. Some accounts allowed you to have unlimited connection time for a flat fee.

Bezeq is very tight-lipped about the exact workings of this software, but it does use Microsoft VPN technology with PPP.

When I opened my account at Urbis, they gave me an account name and a password, and walked me through the process of configuring my Windows machine with a dialup network interface that I could use instead of the black-box Bezeq software.

Basically I configured a new dialup interface using Microsoft VPN which talked to the server 10.0.0.138 "RELAY_PPP1", and which did not use any encryption or compression, used DHCP for IP assignment and DNS server. When I wanted to use ADSL I opened the dialup network interface with my (saved) username and password, and it did the rest.

Linux WOW/ADSL

Now, I wanted to replicate that capability on my Linux machine. In order to create the network connection, we need pptp-linux, and pppd.

We can use the stock ppp daemon shipped with Mandrake 8.1, but unfortunately, Mandrake 8.1 ships with pptp-linux version 1.0.2, which does not allow the user to control the phone number field in the pptp outgoing-call-request, and this field is required for WOW/ADSL. Fortunately, pptp-linux version 1.1.0 from pptp-linux includes a new command-line argument to control that parameter.

One interesting wrinkle is that we are tunnelling IP over ethernet, and our ethernet has a maximum packet size (mtu) of 1500 bytes. The tunnelled packets have an additional IP header added on as they flow over the ethernet, so we have to set the MTU on the tunnelled link to be small enough to ensure that when we add an IP header for the ethernet traffic onto the tunnelled packet which has a tunnelling IP header added to the raw data, we don't overflow the ethernet MTU packet size.

Here is a (partial?) list of the changes and actions I took to get my link working. I may well have forgotten some steps, and I have heard that my one-line patch to pptp-linux doesn't work on all ADSL modems provided by Bezeq.

1. Ensure that you have installed pppd and pptp-adsl from Mandrake 8.1
2. Download pptp-linux-1.1.0-1.tar.gz from pptp-linux
3. Patch pptp-linux-1.1.0-1 to fix a bug with the byte ordering of the phone_len field during pptp_call_open.

   diff -u pptp_ctrl.c.orig pptp_ctrl.c
   --- pptp_ctrl.c.orig    Mon Mar 11 03:51:16 2002
   +++ pptp_ctrl.c Thu May 30 11:11:52 2002
   @@ -238,9 +238,10 @@
        /* fill in the phone number if it was specified */
        if (phonenr) {
            strncpy(packet.phone_num, phonenr, sizeof(packet.phone_num));
   -        packet.phone_len = hton16 (strlen(phonenr));
   +        packet.phone_len = strlen(phonenr);
            if( packet.phone_len > sizeof(packet.phone_num))
                packet.phone_len = sizeof(packet.phone_num);
   +       packet.phone_len = hton16 (packet.phone_len);
        }
   
        if (pptp_send_ctrl_packet(conn, &packet, sizeof(packet))) {
   

4. Build and install pptp-linux over the binaries from pptp-adsl. In particular overwrite /usr/bin/pptp and /usr/bin/pptp_callmgr
5. Edit /etc/ppp/pap-secrets and /etc/ppp/chap-secrets so that they have your username and password from your ISP. This should be identical to the string used as the username in the Windows dialup connection. They should look like:

   # client	server	secret	IP_address
   user@IISP	*	password	*
   *	user@IISP	password	*

6. Update /etc/sysconfig/network-scripts/net_cnx_up to reflect the correct command-line for pptp. You will need to replace the current line with:
   

   /usr/bin/pptp --phone "RELAY_PPP1" 10.0.0.138 user user@IISP \

   persist holdoff 120 noipdefault defaultroute usepeerdns \
   mtu 1450 mru 1450 lcp-echo-interval 60 lcp-echo-failure 3
   

Now, we need to ensure that our new network link actually works. We should run /etc/sysconfig/network-scripts/net_cnx_up, and then check that a connection was created. ifconfig displays all network interfaces, and if the connection was properly created there should be an entry for ppp0.

We also need to check that the routes were properly configured, and we can do this using netstat -rn. There should be a gateway entry for the ppp0 interface.

We can check basic network connectivity using ping or traceroute to any known IP addresses. Initially, I would verify it using only IP addresses, to ensure that we cannot confound DNS problems with network connectivity problems. For example, I might ping www.cs.stanford.edu's address, 171.64.64.64. For more hints on debugging the network connection, you might see the IP masquerade HOWTO for testing IP masquerade.

Firewall and network configuration

Now that we can connect to the network and actually send/receive data over the internet, we have to worry about black hats attacking our recently connected machines. This means that we have to setup and configure a firewall.

We could setup a firewall machine which provides IP forwarding and masquerading so the internal machine simply believes that it is on the internet, or we can setup a proxy firewall where all client accesses to the external network are through proxies on the firewall machine. (Of course, there are a host of intermediate solutions, with some services proxied and others accessed directly, but these are the two extremes.)

I chose to set up a firewall with IP forwarding and masquerading, and I may additionally configure (caching) proxies for some services, such as HTTP and DNS. However, I should like my internal machines to work correctly without requiring the use of any proxy servers.

We have two network interfaces to the outside world, eth1 and ppp0, and we must firewall both interfaces. eth0 is the interface to our internal network, and it should be able to reach anything.

1. Enable IP forwarding by setting FORWARD_IPV4 to "yes" in /etc/sysconfig/network. Note that in Mandrake this causes /etc/rc.d/init.d/network to set /proc/sys/net/ipv4/ip_forward to 1, as is suggested by most HOWTOs and other documentation. However, setting the FORWARD_IPV4 parameter in the script rather than directly setting the ip_forward kernel parameter ensures that the various network configuration scripts do not simply overwrite or override your preferences by getting them to do the right thing.
2. Add a condition to the iptables configuration to clamp the TCP maximum segment size (mss) to the ppp interface's maximum transfer unit (mtu). This is a hack-around to get Windows clients inside the firewall to use the right MTU when talking to external hosts. Using the command line:
   iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

3. Add a number of iptables-related modules to /etc/modules:
   ipt_MASQUERADE
ipt_TCPMSS
ipt_TOS
ip_conntrack_ftp
ip_conntrack_irc
ip_nat_ftp
ip_nat_irc
4. Configure iptables. I store my iptables configuration in iptables-save format, which can be loaded into the kernel using iptables-restore. In Mandrake 8.1 this is the default means of specifying iptables, and it is stored in /etc/sysconfig/iptables. It is automatically loaded by /etc/rc.d/init.d/iptables, which must be enabled using chkconfig.

   My /etc/sysconfig/iptables looks like this:

   *mangle
:PREROUTING ACCEPT 0:0
:OUTPUT ACCEPT 0:0
COMMIT
*filter
:INPUT ACCEPT 0:0
:FORWARD ACCEPT 0:0
:OUTPUT ACCEPT 0:0
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m state --state NEW -i eth1 -j DROP
-A INPUT -m state --state NEW ! -i ppp+ -j ACCEPT
-A INPUT -m state --state NEW -j ACCEPT
-P INPUT DROP
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i ppp+ -o ppp+ -j REJECT
COMMIT
*nat
:PREROUTING ACCEPT 0:0
:POSTROUTING ACCEPT 0:0
:OUTPUT ACCEPT 0:0
-A POSTROUTING -o ppp+ -j MASQUERADE
-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT

My iptables configuration does a number of unusual things:

• disallow new connections from eth1 and ppp+
• masquerade packets from eth0 to eth1 and ppp+
• clamp the MSS for tcp connections to the MTU

Since both eth1 and ppp+ are suspect, I don't allow new connections from either. I would have preferred to write this as:
-A INPUT -m state --state NEW ! -i eth1,ppp+ -j ACCEPT
in a single rule, but iptables doesn't support the specification of multiple interfaces in a single "-i" statement. So, instead, I explicitly drop new connections from eth1 and then use the more standard rule for ppp+.

I allow eth0 to connect to the ADSL modem, since I want the Windows machine to be able to create a PPTP link if necessary. Now that my Linux router is up and stable, this is probably unnecessary.

Conclusions

Now that the connection works, and the firewall is in place, all that remains is to configure all the services for use on the intranet, such as SAMBA.

References

1. http://www.mulix.org/adsl-howto.txt, HOWTO for connecting to Bezeq ADSL.
2. http://tldp.org/HOWTO/Adv-Routing-HOWTO-16.html, advanced routing cookbook.
3. http://pptpclient.sourceforge.net, pptp-linux software for Linux.
4. http://www.samba.org/ppp/, pppd software for Linux.
5. http://reptile.rug.ac.be/~coder/sniffit/sniffit, a network packet sniffer.
6. http://netfilter.samba.org, iptables firewall software for Linux 2.4.
7. Taming the Wild Netfilter, by David A. Bandel, Linux Journal, 89, September 2001. A gentle introduction to iptables.
8. http://www.boingworld.com/workshops/linux/iptables-tutorial, iptables tutorial.
9. http://www.bezeq.co.il/html/wow/default.htm", Bezeq WOW/ADSL.
10. http://www.mandrake.com, Mandrake Linux.
11. http://www.microsoft.com/ie, Microsoft Internet Explorer.