VPN outbound problems: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 22: | Line 22: | ||
[http://te.ugm.ac.id/~ekow/CTF/iCTF_howto.html this site has some examples how to connect using iptables] | [http://te.ugm.ac.id/~ekow/CTF/iCTF_howto.html this site has some examples how to connect using iptables] | ||
iptables -A INPUT -p gre -j ACCEPT | iptables -A INPUT -p gre -j ACCEPT | ||
iptables -A OUTPUT -p gre -j ACCEPT | iptables -A OUTPUT -p gre -j ACCEPT | ||
iptables -A INPUT -p esp -j ACCEPT | iptables -A INPUT -p esp -j ACCEPT | ||
iptables -A OUTPUT -p esp -j ACCEPT | iptables -A OUTPUT -p esp -j ACCEPT | ||
iptables -A eth0_INPUT -p gre -j ACCEPT | |||
iptables -A eth1_INPUT -p gre -j ACCEPT | |||
iptables -A eth0_OUTPUT -p gre -j ACCEPT | |||
iptables -A eth1_OUTPUT -p gre -j ACCEPT | |||
iptables -A eth0_OUTPUT -p esp -j ACCEPT | |||
iptables -A eth1_OUTPUT -p esp -j ACCEPT | |||
iptables -A eth0_INPUT -p esp -j ACCEPT | |||
iptables -A eth1_INPUT -p esp -j ACCEPT | |||
iptables -A FORWARD -p gre -j ACCEPT | |||
iptables -A FORWARD -p esp -j ACCEPT | |||
[http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/VPN-Masquerade-HOWTO.html from here] | [http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/VPN-Masquerade-HOWTO.html from here] | ||
| Line 31: | Line 57: | ||
# The server firewall and ESP: the IPsec encrypted data is carried over IP protocol 50. If the firewall the remote IPsec host is behind does not forward ESP traffic in both directions, IPsec will not work. Again, if you had IPsec working when your IPsec client system directly dialled your ISP then this probably is not the problem. | # The server firewall and ESP: the IPsec encrypted data is carried over IP protocol 50. If the firewall the remote IPsec host is behind does not forward ESP traffic in both directions, IPsec will not work. Again, if you had IPsec working when your IPsec client system directly dialled your ISP then this probably is not the problem. | ||
# The server firewall and GRE: the PPTP data channel is carried as a GRE-encapsulated (IP protocol 47) PPP session. If the firewall your PPTP server is behind does not forward GRE traffic in both directions, PPTP will not work. Again, if you had PPTP working when your PPTP client system directly dialed your ISP then this probably isn't the problem. | # The server firewall and GRE: the PPTP data channel is carried as a GRE-encapsulated (IP protocol 47) PPP session. If the firewall your PPTP server is behind does not forward GRE traffic in both directions, PPTP will not work. Again, if you had PPTP working when your PPTP client system directly dialed your ISP then this probably isn't the problem. | ||
[http://lartc.org/howto/index.html The Linux Advanced Routing & Traffic Control HOWTO has some useful tips] | |||
[http://help.lockergnome.com/vista/Vista-VPN-Cisco-Pix-ftopict11956.html This discussion claims that Vista has no support for MSCHAP v1 in the last message] | |||
[http://www.tek-tips.com/viewthread.cfm?qid=283636&page=1 This is a huge discussion on the not being able to connect issue] | |||
Latest revision as of 17:29, 8 November 2007
First make sure port 1723 is open on the machine you want to connect to On the router using tcpdump -i eth0 host WINDOWSIP and not port 22 and not port 80 on the router (where eth0 is the INTERNAL interface) try to make the connection and look at the data. If you're sending and recieving lots of packets but the final ACKs aren't completing from the remote machine Check if ip masquerading is on /etc/init.d/ipmasq start If there's outgoing traffic to the remote machine but none coming back make sure ip forwarding is allowed echo "1" > /proc/sys/net/ipv4/ip_forward will allow outbound vpn connections. If you do that make sure echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter as well
The router needs to be able to forward port 1723 and 500 traffic. This is usually done with the firewall and ip masquerading. It also needs to be able to forward gre (PPTP - Microsoft) and esp (IPSEC - Cisco) packets.
this site has some examples how to connect using iptables
iptables -A INPUT -p gre -j ACCEPT
iptables -A OUTPUT -p gre -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT
iptables -A OUTPUT -p esp -j ACCEPT
iptables -A eth0_INPUT -p gre -j ACCEPT
iptables -A eth1_INPUT -p gre -j ACCEPT
iptables -A eth0_OUTPUT -p gre -j ACCEPT
iptables -A eth1_OUTPUT -p gre -j ACCEPT
iptables -A eth0_OUTPUT -p esp -j ACCEPT
iptables -A eth1_OUTPUT -p esp -j ACCEPT
iptables -A eth0_INPUT -p esp -j ACCEPT
iptables -A eth1_INPUT -p esp -j ACCEPT
iptables -A FORWARD -p gre -j ACCEPT
iptables -A FORWARD -p esp -j ACCEPT
- The remote firewall: the firewall at the server end must allow a system with the IP address assigned to your Linux box by your ISP to connect to port 500/udp on the IPsec host or port 1723/tcp on the PPTP server. If you had the VPN working when your VPN client system directly dialled your ISP then this probably is not the problem.
- The server firewall and ESP: the IPsec encrypted data is carried over IP protocol 50. If the firewall the remote IPsec host is behind does not forward ESP traffic in both directions, IPsec will not work. Again, if you had IPsec working when your IPsec client system directly dialled your ISP then this probably is not the problem.
- The server firewall and GRE: the PPTP data channel is carried as a GRE-encapsulated (IP protocol 47) PPP session. If the firewall your PPTP server is behind does not forward GRE traffic in both directions, PPTP will not work. Again, if you had PPTP working when your PPTP client system directly dialed your ISP then this probably isn't the problem.
The Linux Advanced Routing & Traffic Control HOWTO has some useful tips
This discussion claims that Vista has no support for MSCHAP v1 in the last message
This is a huge discussion on the not being able to connect issue