1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

1.13 and PPTP Pass through

Discussion in 'Tomato Firmware' started by bhlonewolf, Dec 30, 2007.

  1. bhlonewolf

    bhlonewolf LI Guru Member

    Hey all,

    I'm having trouble setting up PPTP pass through on Tomato 1.13. I'm thinking it's user error, here's the setup. Tomato on a WRT54G, Windows 2003 Server on the LAN with PPTP VPN set up.

    With my laptop on the LAN, I can connect just fine.
    With my laptop on the Internet trying to connect through the router, I can only connect while the Win2K3 server is the DMZ machine.

    Port 1723 is forwarded, and GRE / PPTP Nat Helpers are enabled. But because this only works when the machine is specified as the DMZ, I'm guessing I'm doing something wrong. Any tips?

    Thx,
    Brian
     
  2. Rafatk

    Rafatk Network Guru Member

    Try to forward the port 500 to Win2k3 server also.
    I think having both 1723 and 500 will do the job.

    Rafael
     
  3. bhlonewolf

    bhlonewolf LI Guru Member

    Thanks Rafael-- tried that, no luck. I ran a few more experiments. The setup is:

    my laptop (PPTP Client) -> WRT54G or other router -> Internet -> Tomato -> Win2K3

    I ran the DMZ test again, but found that it only works if I disable the NAT helpers. Next, I tried forwarding 1723 and 500, but no luck. I tried this with both the NAT helpers enabled and disabled.

    I'm wondering if the problem is due to the NAT'ing on both ends? (I hope not, since that's how I typically use this).

    I took a breif snippet from the log file. The 70.x address is my laptop during the test, the 71 is the tomato router with 192.168.1.2 behind it as the PPTP end point.

    Dec 30 13:00:18 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:34 SRC=70.xxx.xxx.xxx DST=71.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=110 ID=23039 PROTO=47
    Dec 30 13:00:18 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:74 SRC=70.xxx.xxx.xxx DST=71.xxx.xxx.xxx LEN=116 TOS=0x00 PREC=0x00 TTL=110 ID=23045 PROTO=UDP SPT=1409 DPT=4500 LEN=96
    Dec 30 13:00:19 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=6479 PROTO=47
    Dec 30 13:00:20 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:34 SRC=70.xxx.xxx.xxx DST=71.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=110 ID=23049 PROTO=47
    Dec 30 13:00:21 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=6482 PROTO=47
    Dec 30 13:00:21 user.warn kernel: ACCEPT IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:34 SRC=70.xxx.xxx.xxx DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=110 ID=23051 DF PROTO=TCP SPT=56092 DPT=443 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020
    Dec 30 13:00:21 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:74 SRC=70.xxx.xxx.xxx DST=71.xxx.xxx.xxx LEN=116 TOS=0x00 PREC=0x00 TTL=110 ID=948 PROTO=UDP SPT=1409 DPT=4500 LEN=96

    Any ideas or suggestions? Thanks!
     
  4. bhlonewolf

    bhlonewolf LI Guru Member

    I ran a couple of more tests, enabling or disabling the PPTP NAT helper ... I'm wondering if there's a problem there? I compared the logs without it, all the GRE 47 packets get dropped, but with it, several of them still get dropped.
     
  5. LLigetfa

    LLigetfa LI Guru Member

    Check to see if some of the packets are out of order. I've read that many firewalls will drop the packets if they arrive in the wrong order.
     
  6. bhlonewolf

    bhlonewolf LI Guru Member

    Hi Lligetfa,

    How can I check that? Thx for the tip!
     
  7. LLigetfa

    LLigetfa LI Guru Member

    Perhaps if you log all (accept and deny) you may be able to follow the sequence numbers.
     
  8. j.m.

    j.m. LI Guru Member

    Try setting Advanced | Firewall | NAT Loopback to "Forwarded Only."
     
  9. bhlonewolf

    bhlonewolf LI Guru Member

    Thanks j.m., tried that, no help I'm afraid.... here's an example of what I'm seeing. The 70.x is external (me), and the 70.x is the home LAN with the 192.168.1.2 server behind it. What I'm thinking the problem is the dropped protocol 47 packets ... though I don't know why....

    Dec 30 14:14:08 user.warn kernel: ip_conntrack_pptp version 1.9 loaded
    Dec 30 14:14:08 user.warn kernel: ip_nat_pptp version 1.5 loaded
    Dec 30 14:14:09 user.warn kernel: ip_conntrack_rtsp v0.01 loading
    Dec 30 14:14:09 user.warn kernel: ip_nat_rtsp v0.01 loading
    Dec 30 14:14:18 user.warn kernel: ACCEPT IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:34 SRC=70.x.x.x DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=110 ID=4510 DF PROTO=TCP SPT=56765 DPT=443 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (0204
    Dec 30 14:14:21 user.warn kernel: ACCEPT IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:34 SRC=70.x.x.x DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=110 ID=4520 DF PROTO=TCP SPT=56766 DPT=443 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (0204
    Dec 30 14:14:52 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:01:87 SRC=42.57.27.23 DST=71.x.x.x LEN=391 TOS=0x00 PREC=0x00 TTL=49 ID=8024 PROTO=UDP SPT=31224 DPT=1026 LEN=371
    Dec 30 14:14:52 user.warn kernel: DROP IN=vlan1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:74:f4:48:01:08:00:45:00:01:5c SRC=10.96.32.1 DST=255.255.255.255 LEN=348 TOS=0x00 PREC=0x00 TTL=255 ID=40180 PROTO=UDP SPT=67 DPT=68 LEN=328
    Dec 30 14:15:00 user.warn kernel: DROP IN=vlan1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:74:f4:48:01:08:00:45:00:01:4a SRC=10.96.32.1 DST=255.255.255.255 LEN=330 TOS=0x00 PREC=0x00 TTL=255 ID=40231 PROTO=UDP SPT=67 DPT=68 LEN=310
    Dec 30 14:15:19 user.warn kernel: ACCEPT IN=vlan1 OUT=br0 SRC=70.x.x.x DST=192.168.1.2 LEN=52 TOS=0x00 PREC=0x00 TTL=109 ID=4647 DF PROTO=TCP SPT=56773 DPT=1723 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405AC0103030801010402)
    Dec 30 14:15:19 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:74 SRC=70.x.x.x DST=71.x.x.x LEN=116 TOS=0x00 PREC=0x00 TTL=110 ID=1261 PROTO=UDP SPT=1430 DPT=4500 LEN=96
    Dec 30 14:15:22 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:69 SRC=70.x.x.x DST=71.x.x.x LEN=105 TOS=0x00 PREC=0x00 TTL=110 ID=4667 PROTO=47
    Dec 30 14:15:23 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7256 PROTO=47
    Dec 30 14:15:24 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:65 SRC=70.x.x.x DST=71.x.x.x LEN=101 TOS=0x00 PREC=0x00 TTL=110 ID=4679 PROTO=47
    Dec 30 14:15:25 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7258 PROTO=47
    Dec 30 14:15:27 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7260 PROTO=47
    Dec 30 14:15:28 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:65 SRC=70.x.x.x DST=71.x.x.x LEN=101 TOS=0x00 PREC=0x00 TTL=110 ID=4689 PROTO=47
    Dec 30 14:15:29 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7261 PROTO=47
    Dec 30 14:15:31 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:65 SRC=70.x.x.x DST=71.x.x.x LEN=101 TOS=0x00 PREC=0x00 TTL=110 ID=4696 PROTO=47
    Dec 30 14:15:31 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7262 PROTO=47
    Dec 30 14:15:32 user.warn kernel: DROP IN=vlan1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:74:f4:48:01:08:00:45:00:01:5a SRC=10.96.32.1 DST=255.255.255.255 LEN=346 TOS=0x00 PREC=0x00 TTL=255 ID=40404 PROTO=UDP SPT=67 DPT=68 LEN=326
    Dec 30 14:15:33 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7263 PROTO=47
    Dec 30 14:15:34 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:65 SRC=70.x.x.x DST=71.x.x.x LEN=101 TOS=0x00 PREC=0x00 TTL=110 ID=4702 PROTO=47
    Dec 30 14:15:35 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7265 PROTO=47
    Dec 30 14:15:37 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:65 SRC=70.x.x.x DST=71.x.x.x LEN=101 TOS=0x00 PREC=0x00 TTL=110 ID=4705 PROTO=47
    Dec 30 14:15:37 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7266 PROTO=47
    Dec 30 14:15:39 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=69 TOS=0x00 PREC=0x00 TTL=127 ID=7267 PROTO=47
    Dec 30 14:15:40 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:65 SRC=70.x.x.x DST=71.x.x.x LEN=101 TOS=0x00 PREC=0x00 TTL=110 ID=4714 PROTO=47
    Dec 30 14:15:41 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=64 TOS=0x00 PREC=0x00 TTL=127 ID=7268 DF PROTO=TCP SPT=1723 DPT=56773 WINDOW=65163 RES=0x00 ACK PSH URGP=0
    Dec 30 14:15:41 user.warn kernel: ACCEPT IN=br0 OUT=vlan1 SRC=192.168.1.2 DST=70.x.x.x LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=7269 PROTO=47
    Dec 30 14:15:42 user.warn kernel: ACCEPT IN=vlan1 OUT=br0 SRC=70.x.x.x DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 TTL=237 ID=5630 PROTO=TCP SPT=56773 DPT=1723 WINDOW=0 RES=0x00 RST URGP=0
    Dec 30 14:15:45 user.warn kernel: DROP IN=vlan1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:05:74:f4:48:01:08:00:45:00:01:4a SRC=10.96.32.1 DST=255.255.255.255 LEN=330 TOS=0x00 PREC=0x00 TTL=255 ID=40500 PROTO=UDP SPT=67 DPT=68 LEN=310
    Dec 30 14:15:59 user.warn kernel: ACCEPT IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:34 SRC=70.x.x.x DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=110 ID=4809 DF PROTO=TCP SPT=56779 DPT=443 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (0204
    Dec 30 14:15:59 user.warn kernel: DROP IN=vlan1 OUT= MAC=00:0f:66:42:b8:fe:00:05:74:f4:48:01:08:00:45:00:00:74 SRC=70.x.x.x DST=71.x.x.x LEN=116 TOS=0x00 PREC=0x00 TTL=110 ID=1262 PROTO=UDP SPT=1430 DPT=4500 LEN=96
     
  10. bhlonewolf

    bhlonewolf LI Guru Member

    Just to follow up -- I decided to play around with it a bit this afternoon. Somehow I still think the GRE NAT helper isn't working quite right (seeing the packets getting dropped), so I disabled it, and ran this script:

    iptables -t nat -I PREROUTING -p 47 -j DNAT --to 192.168.1.2
    iptables -I FORWARD -p 47 -d 192.168.1.2 -j ACCEPT

    I had 1723/TCP already fwd in the port forwards. With this, success! Obviously I'm just fwding all protocol 47 packets to my server, so I'm not sure if this is quite as secure as using the NAT helper (I'm guessing the NAT helper simply opens the ports as needed? Not sure...)

    Any thoughts? In any event, I hope this helps someone else who may need it!
     
  11. TerminatorHTK

    TerminatorHTK LI Guru Member

    Thanks for the information. I also am having trouble with PPTP VPN. I tried the above 2 lines you gave (substituting my address of course for the VPN server) and was unsuccessful in still getting it to work. I had manually entered the lines by using putty to SSH into the router remotely. That should be the same as running them via a startup script?

    Any other things you might have done to make this work besides those 2 lines?

    Thanks
     
  12. bhlonewolf

    bhlonewolf LI Guru Member

    Hmmm -- are you also forwarding 1723? At first I had the 1723 fwd in the port forwards on the web gui, but to keep it all in one place I ultimately just put it in the firewall bootup script. So, without setting anything else up, the total soluttion should like like:

    iptables -t nat -I PREROUTING -p tcp --dport 1723 -j DNAT --to 192.168.1.2:1723
    iptables -I FORWARD -p tcp -d 192.168.1.2 --dport 1723 -j ACCEPT

    iptables -t nat -I PREROUTING -p 47 -j DNAT --to 192.168.1.2
    iptables -I FORWARD -p 47 -d 192.168.1.2 -j ACCEPT

    There are a few situations where I can't connect -- for example, through my mobile phone tethered to my laptop. I haven't troubleshooted this, but I'm assuming the connection simply won't relay certain traffic for one reason or another. Not much I can do about that, but in these cases I've just used SSH which, so far, seems to work on everything I've tested it on.
     
  13. TerminatorHTK

    TerminatorHTK LI Guru Member

    Hmmm...thats strange. I am using port forwarding for 1723 via the GUI, but since that's just a plain TCP port forward like any other, I would assume that would work. In any case, I tried doing it all via the lines you gave and still got the same result. The message in the event log on the 2003 server implies that GRE communication is the problem. I can see the GRE traffic passing the firewall here at work (since I'm firewall administrator), so I know it's going out. I'll keep trying I guess...
     
  14. TerminatorHTK

    TerminatorHTK LI Guru Member

    I've looked through the logs for my PPTP attempts, and I'm finding the following statement whenever an attempt for PPTP VPN was made. This occurs regardless of whether I had added the statements from previous posts via putty or not.

    2008/01/03 09:03:53.74 M <13>kernel: ip_conntrack_pptp.c: bad csum

    Any ideas why I would be receiving this in the logs? Anything I can do to try and correct this?

    Thanks
     
  15. bhlonewolf

    bhlonewolf LI Guru Member

    Did you disable the GRE/PPTP Nat Helper in advanced -> conntrack? Give that a try -- I need to keep it disabled on mine (sorry for forgetting to mention that before!)
     
  16. TerminatorHTK

    TerminatorHTK LI Guru Member

    I did disable it, but I didn't reboot the router. There were other computers using the internet at the time. I'll try disabling, then rebooting the router, and trying it.
     
  17. TerminatorHTK

    TerminatorHTK LI Guru Member

    I'm convinced there is a problem with the PPTP passthru (GRE packets) and will probably give up for now since I have workarounds. I'm using RDP forwarded to various PCs using different ports.

    Hopefully this can be fixed in a future version? Is there anyway to report this as a problem to try and get it fixed?
     
  18. bhlonewolf

    bhlonewolf LI Guru Member

    Yep, you can submit a bug report (I believe his contact info is towards the bottom of the FAQ page?)...

    But, I'm running 1.13 and I can pass GRE using the script I posted above -- the NAT helper definitely doesn't work, at least in my configuration. I've looked at the source (which is the same as DD-WRT's, IIRC -- I don't think either firmware changed the NAT helpers) and it looks pretty fragile.

    As long as I keep 1723 and proto 47 packets forward, and the GRE helper disabled, I'm good, with the exception of some situations like tethering to a cell phone, but I have to assume the problem is with the phone.
     
  19. bhlonewolf

    bhlonewolf LI Guru Member

    I flashed back to DD-WRT and I couldn't get PPTP pass through to work on DD-WRT. I don't think PPTP is very NAT friendly, though I thought I had it working on it before. Perhaps I was just using the PPTP server built into DD-WRT? I can't remember as it has been so long.
     
  20. bhlonewolf

    bhlonewolf LI Guru Member

    Ouch, well, back to the drawing board for me. This whole time, I've been figuring out how to connect _into_ my home network when I'm on the road. I neglected the fact that I also VPN _out_ into my corporate network, over PPTP.

    The end result is that I can't do both. Yeah, I could change settings remotely as I obviously can't be both home AND away at the same time, but I don't like that solution. I guess I still have SSH, but it's not as elegant.
     
  21. TerminatorHTK

    TerminatorHTK LI Guru Member

    Well I'm hoping that the next version of Tomato might include some fixes for the PPTP passthru issue. In the meantime, I'm accessing my PCs by forwarding ports to 3389 for the various PCs to use RDP. I can also get at the router by other various means, so it's not a show stopper for me...but it would be nice.
     
  22. kevanj

    kevanj LI Guru Member

    Buffalo WHR-HP-G54 w/Tomato 1.13 - PPTP passthru works fine for me using only the helper option. I originally thought not, but it appears that the GRE response packets are not making it back to my PC at work (firewall issue I assume). Tested from a family member's house (Verizon FIOS) and it worked fine.
     
  23. beezageeza

    beezageeza LI Guru Member

    Yes, works for me also when forwarding to VPN server on lan.

    However, what I want to do is to forward from Internet router (WRT54GS Tomato 1.13) onto an "internal router" (BEFSR41), and from there to the VPN server on the "internal network".

    Should that work - even in theory? It's not at the moment.
     
  24. kevanj

    kevanj LI Guru Member

    Is the SPI firewall switched on on the internal router? If so you might try switching it off if you don't need it (assuming the FW is on at the Internet router).
    You will also need a static route on your external router to tell it where to send traffic for the network behind the internal router. The route should point to the IP on the external interface of the internal router (probably the WAN interface, if that is how you have it cabled. I'd venture to guess the 'internal' router is running in 'router' mode, as opposed to 'gateway' mode???
     

Share This Page