Bekijk de volledige versie : vpn connection from client with pptp (ms vpn)
Hello all,
Since 2 days I own an ASUS WL-500G, and I am more than pleased with the device. I've set up firewalling, and off course, if I want to do some work from home I have to use a vpn connection to the office.
We use pptp (vpn as implemented in microsofts windows xp), but somehow while I have firewalling active, I can't seem to get a connection to the office network.
I've set lan to wan and wan to lan firewall both on drop if not on list, and I've put port 1723 on the list (and all ports I want to use).
I have the feeling it is gre (generic Routing Encapsulation) protocol that is getting blocked somehow). I did try to open up port 47 as well, but it is protocol type 47 and not really port 47.
Even if I put the host where I want to connect to in the list (once in destination and once in source) I still cannot get a vpn connection.
Funny thing is, I had no difficulties in getting the cisco vpn client (also used for different location) working.
My Asus is currently running 1.8.1.7-3 (from Oleg), but I've also tried this with the asus versions.
Anyone an idea how to get this working?
Thanks in advance,
Oscar
I use a Windows XP SP1 client to connect to my office which is running a Linux VPN server. This has worked well from the very first attempt. I also use 1.8.1.7 CR3.
Have you tried with a disabled firewall on the Windows client?
Disable both "LAN to WAN Filter" and "WAN to LAN Filter" and try again.
It will work with the firewalls disabled. I was hoping to find a way to get it running with the firewalls up.
But that is not possible?
I Have my WAN to LAN filter active, so I guess its the LAN to WAN who's causing the trouble. This firewall isn't very nessesary, so you can shut it down and raise the WAN to LAN firewall again.
I Have my WAN to LAN filter active, so I guess its the LAN to WAN who's causing the trouble. This firewall isn't very nessesary, so you can shut it down and raise the WAN to LAN firewall again.
Hmmz, the last one is a matter of opinion
:D
I'll have a go at disabling the lan to wan firewall, and see if I get it going.
Thanks all so far!
Well, WAN to LAN firewall is not needed if you've configured wl500g in the home gateway mode, NAT is performing filtering.
As for LAN to WAN - do you need this at all? You treat your local LAN as unreliable?
Anyway, this looks like a problem in the firmware, if it's still does not work. GRE should be automatically forwarded anyway, but this needs correct automatically generated rules...
Can you please run
iptables -L -v -n
from the hidden admin page?
well, I get a little bit further, when I have the lan 2 wan firewall disabled and I set up a vpn tunnel it now says verifying username and password, and then it times out and states a 619 disconnected error (port used for this connection was closed).
Eventhough port 47 tcp and port 1723 tcp are on the list of accepted ports.
I am kinda puzzled bout it.
Any one an idea?
Well, WAN to LAN firewall is not needed if you've configured wl500g in the home gateway mode, NAT is performing filtering.
As for LAN to WAN - do you need this at all? You treat your local LAN as unreliable?
I still like to have a firewall between the www and my lan. I know Nat is filtering, but I like to be on the safe side. And I don't treat my lan as unreliable, I just don't want connections to the internet that aren't "normal".
I did a telnet and captured the output:
[admin@wizhost root]$ iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
2225 145K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
65 3900 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
state NEW
90 8499 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
state NEW
142 20707 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 5933 packets, 373K bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
99 4752 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:0x16/0x02 limit: avg 1/sec burst 5
41 1640 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:0x17/0x04 limit: avg 1/sec burst 5
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
limit: avg 1/sec burst 5 icmp type 8
1291 1336K ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:80
6 240 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:5190
210 25298 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:1863
41 15587 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:443
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:110
4239 5842K ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:119
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:53
0 0 ACCEPT udp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
udp spt:53
40 2496 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:1723
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:143
0 0 ACCEPT udp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
udp spt:500
0 0 ACCEPT udp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
udp spt:4500
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:10000
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:25
0 0 ACCEPT udp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
udp spt:123
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:47
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:6112
8 372 DROP all -- eth1 br0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 2307 packets, 1114K bytes)
pkts bytes target prot opt in out source destination
Chain logaccept (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
state NEW LOG flags 7 level 4 prefix `ACCEPT '
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain logdrop (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
state NEW LOG flags 7 level 4 prefix `DROP'
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
This is with the lan 2 wan firewall disabled.
Well, if it isn't possible, I can indeed switch the firewall off whenever the vpn tunnel is needed, it would be nice if it would work with firewalls enabled.
regards,
Oscar
Bunzzing
19-12-2004, 20:52
Well, WAN to LAN firewall is not needed if you've configured wl500g in the home gateway mode, NAT is performing filtering.
As for LAN to WAN - do you need this at all? You treat your local LAN as unreliable?
Better safe than sorry.....
Most people think that NAT will block everything. How about traffic from your LAN to WAN for eg trojans and other virusses. I bet the standard NAT "firewall" doesn't do anything about that. Traffic from the inside is considdered to be safe according to most NAT tables.
My wl500g is operating in AP only mode, but I'm thinking of replacing my "old" dreytek router with the wl500g. One thing will be sure, I will definately enable Lan2Wan and Wan2Lan firewalls.
This is with the lan 2 wan firewall disabled.
I need the same with firewall enabled, to figure out the problem.
Most people think that NAT will block everything. How about traffic from your LAN to WAN for eg trojans and other virusses. I bet the standard NAT "firewall" doesn't do anything about that. Traffic from the inside is considdered to be safe according to most NAT tables.
That is why I'm talking of WAN to LAN, which is filtered by NAT and RELIABLE LAN, which is not filtered.
Well, if it isn't possible, I can indeed switch the firewall off whenever the vpn tunnel is needed, it would be nice if it would work with firewalls enabled.
regards,
Oscar
If you are familar with iptables and custom firmware. ;-)
So, just add this line to your post-firewall script:
iptables -I FORWARD -p 47 -j ACCEPT
This should enable all GRE traffic.
I need the same with firewall enabled, to figure out the problem.
Ok, I've enabled both again.
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
688 39233 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
6 360 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
state NEW
29 1958 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
state NEW
1 148 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID
0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
2 96 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:0x16/0x02 limit: avg 1/sec burst 5
1 40 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp flags:0x17/0x04 limit: avg 1/sec burst 5
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
limit: avg 1/sec burst 5 icmp type 8
4 236 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:80
2 165 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:5190
0 0 ACCEPT udp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
udp dpt:123
12 563 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:110
0 0 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:119
0 0 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:143
0 0 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:53
0 0 ACCEPT udp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
udp dpt:53
0 0 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:25
0 0 ACCEPT udp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
udp dpt:500
0 0 ACCEPT udp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
udp dpt:4500
0 0 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:10000
0 0 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:1723
0 0 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:443
18 2288 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:1863
0 0 ACCEPT tcp -- br0 eth1 0.0.0.0/0 0.0.0.0/0
tcp dpt:47
0 0 DROP all -- br0 eth1 0.0.0.0/0 0.0.0.0/0
3 128 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:80
2 309 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:5190
14 2599 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:1863
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:443
15 4800 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:110
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:119
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:53
0 0 ACCEPT udp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
udp spt:53
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:1723
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:143
0 0 ACCEPT udp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
udp spt:500
0 0 ACCEPT udp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
udp spt:4500
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:10000
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:25
0 0 ACCEPT udp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
udp spt:123
0 0 ACCEPT tcp -- eth1 br0 0.0.0.0/0 0.0.0.0/0
tcp spt:47
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:6112
0 0 DROP all -- eth1 br0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 701 packets, 439K bytes)
pkts bytes target prot opt in out source destination
Chain logaccept (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
state NEW LOG flags 7 level 4 prefix `ACCEPT '
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain logdrop (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0
state NEW LOG flags 7 level 4 prefix `DROP'
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
I've noticed that even though port 47 is in the accept list, it says dropped in here?
Anyway, this is with lan 2 wan and wan 2 lan firewall enabled.
regards,
Oscar
port 47 is not protocol 47.
Ok, I've identified the problem.
You need to execute this
iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
and it should start working. Please check this.
Well ASUS guys has no idea, that they're doing... Firewall shit continues over and over...
If you are familar with iptables and custom firmware. ;-)
So, just add this line to your post-firewall script:
iptables -I FORWARD -p 47 -j ACCEPT
This should enable all GRE traffic.
tried this by hand, and now it works. Vpn connection is running nicely now.
It seems that even though I put port 47 on the list of accepted ports it shows up as dropped instead of accepted.
But this rule will correct that so this is working like a charm now.
Thanks to point me in the right direction!
regards,
Oscar
port 47 is not protocol 47.
Ok, I've identified the problem.
You need to execute this
iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
and it should start working. Please check this.
Well ASUS guys has no idea, that they're doing... Firewall shit continues over and over...
That works too.
I've rebooted the asus, and tried again without any changes. Then I've applied this line and it worked.
Thanks again
Oscar
Oleg, is this a firewall/nat problem for all firmwares? I mean: Does everybody needs to apply this rule ?
Ok, I've tested both.
but witch one is preferable?
iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
or
iptables -I FORWARD -p 47 -j ACCEPT ?
I've put iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT into my post-firewall, and after a reboot I am still able to get a vpn connection.
regards,
oscar
After reading Oleg' message i think you set the right rule at this point.
Oleg, is this a firewall/nat problem for all firmwares? I mean: Does everybody needs to apply this rule ?
Yes, starting with new buggy 1.8.x.x series.
Ok, I've tested both.
but witch one is preferable?
iptables -I FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
This one. It tracks connection, opening GRE only then needed. The same applies to ftp-data connections.
Thanks again in pointing me in the right direction, it now runs like a charm.
regards,
Oscar