PFW est un frontend web pour PF (OpenBSD Packet Filter). Voici un petit patch indispensable pour permettre d’éditer correctement les règles de NAT (version 0.7.8). D’autres patches suivront peut-être car de nouveaux bugs nous ont déjà été reportés.
I use Nokia 6630 phone and Orange (french mobile phone provider).
Plug it with USB (you must have /dev/ttyACM0).
apt-get install ppp wvdial
And create these 3 files.
/etc/ppp/peers/gprs file:
lcp-echo-failure 0 lcp-echo-interval 0 nodetach debug show-password connect "/usr/bin/wvdial --chat --config /etc/ppp/peers/gprs-wvdial.conf foo" disconnect /etc/ppp/peers/gprs-disconnect-chat /dev/ttyACM0 115200 # fast enough crtscts # serial cable, Bluetooth and USB, on some occations with IrDA too local :10.0.0.1 noipdefault ipcp-accept-local defaultroute usepeerdns novj nobsdcomp novjccomp nopcomp noaccomp noauth user "user"
/etc/ppp/peers/gprs-wvdial.conf file:
[Dialer foo] Init1 = ATH Init2 = ATE1 Init3 = AT+CGDCONT=1,"IP","orange.fr","",0,0 Dial Command = ATD Phone = *99# Username = orange Password = orange
/etc/ppp/peers/gprs-disconnect-chat file:
#!/bin/sh exec /usr/sbin/chat -V -s -S ABORT "BUSY" ABORT "ERROR" ABORT "NO DIALTONE" SAY "nSending break to the modemn" "" "K" "" "+++ATH" SAY "nPDP context detachedn"
Finally you can:
pppd call gprs
Note that with Orange you can’t use SSH port (port 22) but others classical ports are enabled: 21, 25, 80, 110, 143, 443, 993 and 995.
My mission of this week-end was to secure the France Telecom ADSL access of my parents. ADSL connection is made with Livebox, a router/modem box. But it’s not easy to manage (no command-line access, limited functionnalities) then I shut down DHCP and Wi-Fi on Livebox and put a famous WRT54G to have powerful and secure services. Of course, I used OpenWRT with dnsmasq (small and flexible DNS cache and DHCP), dropbear (SSH server) and network utilities (tcpdump, nmap, iptables, snmpd). For Wi-Fi connectivity, I configured access point to have WPA2/EAP/PSK with a 63 random-characters passphrase. All tests were OK with Windows XP native WPA client, Linux wpa_supplicant or even Nintendo Wii box.
Mission Accomplished!
Si toi aussi, lorsque tu te retrouves devant un problème réseau étrange (ou plutôt derrière un routeur boîteux), tu tentes systématiquement les astuces les plus courantes mais que tu oublies pendant plusieurs minutes celle qui s’applique (comme par hasard), voici le faux script magique pour ta machine Linux :
http://www.gcolpart.com/hacks/rezal-repair
Certes, tu vas me dire que si tu es sur cette page, c’est que tu n’as pas de problème réseau, mais justement, sois prévoyant, just wget it!
Note : ceci sera très utile aux membres du PLUG avec la connexion bancale Club Internet que l’on a lors des réunions mensuelles.
With nss_ldap Debian unstable host, when I start a lot of softwares (XTerm, bash, top, xmms, etcetera), there is a reverse DNS query for LDAP server. I don’t know why there is this reverse DNS query !!
The problem is when this reverse DNS query fails and you use Avahi daemon : all this softwares start after 2 or 3 seconds. Example, if I start XTerm… I wait 3 seconds… Xterm window appears … I wait 3 seconds… bash prompt appears : WTF.
Workarounds could be :
- Add line for LDAP server in /etc/hosts
- Have reverse DNS entrie in DNS server
- Disable Avavhi daemon use in nsswitch.conf
PPTP VPN gateway can avoid various constraints : single connection, delay for switching VPN between two hosts, etc.
Here is an easy solution :
- Install Debian with ppp and pptp-linux packages
- RTFM and create /etc/ppp/options.pptp file :
lock noauth nobsdcomp nodeflate
And /etc/ppp/peers/my-tunnel file :
pty "pptp SERVER-IP --nolaunchpppd" name LOGIN remotename PPTP require-mppe-128 file /etc/ppp/options.pptp ipparam my-tunnel
where LOGIN is your PPTP login.
Put Microsoft CHAP parameters in /etc/ppp/chap-secrets file :
LOGIN PPTP PASSWORD *
where PASSWORD is your PPTP password.
Then, PPTP connection is ready.
Add it in interfaces file :
auto mobile iface mobile inet ppp provider my-tunnel up sleep 10 && route add -net 192.168.x.0/24 dev ppp0 up route add -net 192.168.y.0/24 dev ppp0 up /etc/init.d/firewall start
In this example, 192.168.x.0/24 and 192.168.y.0/24 are in VPN network.
And /etc/init.d/firewall file is easy IPTables script :
#!/bin/sh # just route it ! echo 1 > /proc/sys/net/ipv4/ip_forward echo 0 > /proc/sys/net/ipv4/tcp_ecn iptables -t nat -D POSTROUTING -o ppp0 -j MASQUERADE iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # MTU in tunnel (only for Windows machines... strange) iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu
(update : I use now "--set-mss 294" option after some problems with "--clamp-mss-to-pmtu")
iptables -L --line-numbers iptables -L -t nat --line-numbers
Then, to enable or disable your PPTP VPN Gateway :
# ifup mobile # ifdown mobile
I had a strange problem: TCP freeze after HTTP GET with particular web sites (but no problem for HTTP HEAD for example) when I use machines with 2.6.17 Linux (Debian) kernel. I find why. Use of TCP window scaling changes in 2.6.17 and some broken routers don’t like this. Here is interesting discussion about use of TCP window scaling.
For my problem, fast (and bad) work around is:
echo 0 > /proc/sys/net/ipv4/tcp_default_win_scale
or even:
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
At work, we have cheap network cards for tests.
From the last command, cards are announced to be classic Realtek RTL8139D chip.
But when I put in Linux 2.(4|6) systems, I discover curious lspci message :
Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 86) Subsystem: VIA Technologies, Inc.: Unknown device 0105
And with pci-id 1106:3106 (rev 86), I found on PCI IDs database the reference :
3106 VT6105 [Rhine-III] 1186 1403 DFE-530TX rev C
On Linux, this chipset seems to be a VIA Rhine chipset and it works fine with via-rhine Linux driver. On Windows XP, card is recognized as Realtek card and works with Realtek driver. On OpenBSD, card works with vr driver…
MAC address confirms me that is Realtek card : http://www.coffer.com/mac_find/?string=00%3AE0%3A4C
Then I have VIA chipsets marked as Realtek Chipsets !
Perhaps a factory error…
Suite à une présentation succinte sur IPv6 au cours de la réunion du PLUG de novembre 2005, voici les slides que j’ai utilisé :
