Hi
I routed 2 vpn connections on my wrt54gl between a local network and two vpn client on internet:
prerouting_wan
target prot opt in out source destination
DNAT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1494 to:192.168.0.152:1494
DNAT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1493 to:192.168.0.152:1493
forwarding_wan
target prot opt in out source destination
ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1493:1500
Theses rules are added (append) in my firewall.user. I mean the kamikaze default rules are still in use.
The VPN server listen to on 1493 and 1394 UDP ports for each vpn client on the internet. I first had a problem with the initial forwarding port rules:
initial forwarding_wan
target prot opt in out source destination
ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1493
ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1494
The VPN connection was losed every day (not necessary each 24 hours because of the ppp restart of my internet provider).
I noticed that the vpn packets came through the prerouting rules and were stopped on the forwarding rule, because the port number changed (??!!): Actually the new port was 1497 (for the initial 1494 port) ...
So when I used the new rule (forward of 1493 to 1500 UDP ports) to fix the problem.
The only explanation for me to this weird thing (except the fact that vpn changed its listenning ports) comes from the MASQUERADE use: the output packets was tagged for response (with automatic adress translation) so the returned packets bypassed the prerouting rule (because of the dynamic masquerade rule) and were stopped only on forwarding rule (because of the new UDP port...)
Now, again, every day, I lose the vpn connection. On kamikaze side, there are no suspicious logged packets (wrong ports or address) whatever are the rules.
I tried a vpn client and/or server restart, a iptables reload, nothing changed.
The only option is the wrt45gl reboot.
I saw on another post that I could solve it by adding iptables-mod-nat and kmod-ipt-nat package, but it doesn't solve anything.
Maybe there is a interact problem with the use of pppoe, iptables ?
Please notice that I didn't have this problem with the white russian version.
I'll be very pleased if someone could help me :-)
Here is my configuration:
----------- ---------- -------------
VPN client| <---> | wrt45g | <---> | VPN server |
----------- ---------- -------------
kamikaze 7.07 - linksys wrt54gl
Linux version 2.4.34 (nbd@ds10) (gcc version 3.4.6 (OpenWrt-2.0)) #3 Sun Sep 30 20:33:21 CEST 2007
config interface wan
option ifname "eth0.1"
option proto pppoe
option username "***"
option password "***"
option demand
option mtu 1400
option maxfail 0
option idle 10
base-files-brcm-2.4 - 10-9078 -
bridge - 1.0.6-1 -
busybox - 1.4.2-2 -
dnsmasq - 2.39-1 -
dropbear - 0.50-2 -
iptables - 1.3.7-1 -
iptables-mod-nat - 1.3.7-1 -
iptables-mod-ulog - 1.3.7-1 -
iptraf - 3.0.0-1 -
kernel - 2.4.34-brcm-1 -
kmod-brcm-wl - 2.4.34+4.80.53.0-1 -
kmod-diag - 2+2.4.34-brcm-1 -
kmod-ipt-nat - 2.4.34-brcm-1 -
kmod-ipt-nathelper - 2.4.34-brcm-1 -
kmod-ipt-ulog - 2.4.34-brcm-1 -
kmod-ppp - 2.4.34-brcm-1 -
kmod-pppoe - 2.4.34-brcm-1 -
kmod-switch - 2.4.34-brcm-1 -
kmod-wlcompat - 2.4.34+brcm-6 -
libgcc - 3.4.6-10 -
libmysqlclient - 5.0.18-1 -
libncurses - 5.6-1 -
mtd - 5 -
nas - 4.80.53.0-1 -
ntpclient - 2003_194-4 -
nvram - 1 -
ppp - 2.4.3-8 -
ppp-mod-pppoe - 2.4.3-8 -
uclibc - 0.9.28-10 -
ulogd - 1.24-1 -
ulogd-mod-mysql - 1.24-1 -
wireless-tools - 29-1 -
wlc - 4.80.53.0-1 -
zabbix-agent - 1.3.2-1 -
zlib - 1.2.3-4 -
Module Size Used by Tainted: P
wlcompat 14944 0 (unused)
ipt_ULOG 3760 3
ip_conntrack_tftp 1712 0 (unused)
ip_nat_irc 2336 0 (unused)
ip_conntrack_irc 3128 1
ip_nat_ftp 2960 0 (unused)
ip_conntrack_ftp 4272 1
ipt_NETMAP 624 0 (unused)
ipt_REDIRECT 640 0 (unused)
ipt_MIRROR 1296 0 (unused)
ppp_async 7884 0 (unused)
wl 630776 0 (unused)
pppoe 9320 1
pppox 1196 1 [pppoe]
ppp_generic 22300 3 [ppp_async pppoe pppox]
slhc 6064 0 [ppp_generic]
switch-robo 4540 0 (unused)
switch-core 4864 0 [switch-robo]
diag 25520 0 (unused)
(Last edited by zgalki on 15 Feb 2008, 09:58)