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

incoming PPTP connections getting dropped by firewall

Discussion in 'Tomato Firmware' started by Powerkraut, Jan 2, 2014.

  1. Powerkraut

    Powerkraut Reformed Router Member

    Hi there,

    I am running Tomato Shibby (current build) on a RT-N66U, and have been connecting to my router via PPTP ever since without any problems.

    However, without any indication why, since today, I can no longer connect via PPTP anymore.

    It seems I can reach the router ok, though, because the log shows ppp entries, however, the router seems to drop those, and I honestly can't figure out why:

    Code:
    Jan  2 10:03:25 asus user.alert kernel: DROP  <4>DROP IN=ppp0 OUT= MAC= <1>SRC=195.4.xxx.xxx DST=88.217.xxx.xxx <1>LEN=472 TOS=0x00 PREC=0x00 TTL=56 ID=9480 PROTO=UDP <1>SPT=61698 DPT=51405 LEN=452 
    Rebooting the router didn't help.

    Would anyone be able to help me find the cause for this? Where should I look?

    Thanks!
     
  2. koitsu

    koitsu Network Guru Member

    This would be a good start, wrapped in separate code blocks please:

    iptables -L -n -v --line-numbers
    iptables -t nat -L -n -v --line-numbers


    One of your iptables rules is using the log capability, which is why you're seeing said log entries.

    P.S. -- What port number is PPTP listening on? Because the above log entry shows a client of 195.4.xxx.xxx (source port 61698) trying to connect to 88.217.xxx.xxx, via UDP protocol, on port 51405. If PPTP isn't listening on one of those ports, then you probably have an iptables rule that is blocking your legit PPTP packets, which would mean you have a rule ordering problem. This is extremely common around here, when people go "making their own rules" and start using iptables -I and iptables -A without understanding the implications of how firewalls works (re: where you insert/add a rule matters!).

    P.P.S. -- In the future, please do not obscure IP addresses or other such information with "xxx" marks. It makes troubleshooting impossible, especially with firewall rules. Doing this will cause some folks (i.e. me) to ignore what's said; network administrators will not debug issues when information is hidden/obscured.
     
  3. Powerkraut

    Powerkraut Reformed Router Member

    Apologies for obscuring the IP addresses, and thanks for still answering :)
    I have not done anything with iptables in terminal, I only work in the GUI.

    I even went so far now and reset the NVRAM (thorough) and started from scratch, only to see the problem is still there. So it seems that there are some settings in GUI, which seem to do this.

    Anyway, here are the two commands:

    Code:
    root@asus:/tmp/home/root# iptables -L -n -v --line-numbers
    Chain INPUT (policy DROP 0 packets, 0 bytes)
    num   pkts bytes target     prot opt in     out     source               destination        
    1        5   323 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
    2      350 64530 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    3        3   192 shlimit    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW
    4        1    67 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0          
    5      704 87854 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0          
    6       81 10646 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0          
    7        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1723
    8        0     0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0          
    
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    num   pkts bytes target     prot opt in     out     source               destination        
    1    12216 4836K            all  --  *      *       0.0.0.0/0            0.0.0.0/0           account: network/netmask: 10.1.2.0/255.255.255.0 name: lan
    2        0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0          
    3        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
    4      733 45196 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    5     6004 3424K L7in       all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          
    6    11829 4811K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    7        8   480 wanin      all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          
    8      379 24990 wanout     all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0          
    9      379 24990 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0          
    10       8   480 upnp       all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          
    
    Chain OUTPUT (policy ACCEPT 410 packets, 175K bytes)
    num   pkts bytes target     prot opt in     out     source               destination        
    
    Chain L7in (1 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    1        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto skypetoskype
    2        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto youtube-2012
    3        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto flash
    4        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto httpvideo
    5     1913 1501K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto rtp
    6        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto rtmp
    7        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto rtmpt
    8        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto shoutcast
    9        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto irc
    
    Chain logdrop (2 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    1       81 10646 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW limit: avg 1/sec burst 5 LOG flags 39 level 4 prefix `DROP '
    2       81 10646 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0          
    
    Chain logreject (0 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 1/sec burst 5 LOG flags 39 level 4 prefix `REJECT '
    2        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with tcp-reset
    
    Chain shlimit (1 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    1        3   192            all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: SET name: shlimit side: source
    2        0     0 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source
    
    Chain upnp (1 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    1        8   480 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.1.2.112          tcp dpt:32400
    
    Chain wanin (1 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    1        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.1.2.112          tcp dpt:6889
    
    Chain wanout (1 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    
    Code:
    root@asus:/tmp/home/root# iptables -t nat -L -n -v --line-numbers
    Chain PREROUTING (policy ACCEPT 2016 packets, 235K bytes)
    num   pkts bytes target     prot opt in     out     source               destination        
    1      215 27096 WANPREROUTING  all  --  *      *       0.0.0.0/0            82.135.88.143      
    2        0     0 DROP       all  --  ppp0   *       0.0.0.0/0            10.1.2.0/24        
    3        0     0 DNAT       udp  --  *      *       10.1.2.0/24         !10.1.2.0/24         udp dpt:53 to:10.1.2.1
    4      215 27096 upnp       all  --  *      *       0.0.0.0/0            82.135.88.143      
    
    Chain POSTROUTING (policy ACCEPT 16 packets, 3641 bytes)
    num   pkts bytes target     prot opt in     out     source               destination        
    1      736 50498 MASQUERADE  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0          
    2       24  9760 SNAT       all  --  *      br0     10.1.2.0/24          10.1.2.0/24         to:10.1.2.1
    
    Chain OUTPUT (policy ACCEPT 109 packets, 17528 bytes)
    num   pkts bytes target     prot opt in     out     source               destination        
    
    Chain WANPREROUTING (1 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    1        0     0 DNAT       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           to:10.1.2.1
    2        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:6889 to:10.1.2.112
    
    Chain upnp (1 references)
    num   pkts bytes target     prot opt in     out     source               destination        
    1        8   480 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:9545 to:10.1.2.112:32400 
     
  4. koitsu

    koitsu Network Guru Member

    Looks like the packets in question are hitting rule #6 in the INPUT chain (the one with the target called "logdrop").

    It appears to me that rules #7 and #8 need to come before rule #6 for things to work properly. Those two rules are what permit inbound PPTP connections (rule #6) and inbound GRE (IPsec) packets (rule #7).

    A workaround would be the following, placed into Scripts -> Firewall -- but please try this from the CLI first to make sure it works.

    line=`iptables -L INPUT -n -v --line-numbers | awk '/logdrop/ { print $1 }'`
    iptables -I INPUT $line -p 47 -j ACCEPT
    iptables -I INPUT $line -p tcp --dport 1723 -j ACCEPT
    unset line


    What this should do is insert the two aforementioned firewall rules "in front" of the logdrop rule (i.e. the logdrop rule, when this is done, will become rule #8).

    There will be two remaining entries (rule #9 and rule #10) which are identical to the inserted rules, and those rules will never be matched.

    Do not add this to Scripts -> Firewall until you've tested it and made sure things work right. Be aware that toggling other GUI features relating to anything network-related may break this workaround and cause you problems. Consider this your warning.

    If this doesn't work, then the other possibility is that there is a downright missing firewall rule for permitting all input traffic across the ppp0 interface, as I noticed the kernel log message is for the ppp0 interface (I believe that would be your PPPoE interface?). And that would be as easy as this:

    line=`iptables -L INPUT -n -v --line-numbers | awk '/logdrop/ { print $1 }'`
    iptables -I INPUT $line -i ppp0 -j ACCEPT
    unset line


    However please know that I do not know the implications of adding this rule -- it could be a security issue. I'd wait for someone more experienced to comment on if doing this is the correct solution or not.

    @shibby20 should be able to look into this and fix it in a future firmware update.

    I cannot help past this point. Sorry.
     
    Last edited: Jan 4, 2014
  5. darkknight93

    darkknight93 Networkin' Nut Member

    My roules are:

    Code:
    Add to Administration/Scripts/Firewall - no need to reboot.
    #!/bin/sh
    iptables -A INPUT -p tcp —dport 1723 -j ACCEPT
    iptables -A INPUT -p gre -j ACCEPT
    iptables -A INPUT -i ppp+ -j ACCEPT
    iptables -A FORWARD -i ppp+ -j ACCEPT
    iptables -A FORWARD -o ppp+ -j ACCEPT
    iptables -t nat -I PREROUTING -p tcp —dport 1723 -j ACCEPT
    iptables -I INPUT -p tcp —dport 1723 -j ACCEPT
    iptables -I INPUT -i ppp+ -j ACCEPT
    iptables -I FORWARD -i ppp+ -j ACCEPT
    
     
  6. Powerkraut

    Powerkraut Reformed Router Member

    Thank you @kotisu and @darkknight83.

    I will try your suggestions today.

    I wonder, why I am having this issue just now. My PPTP used to work just fine for months. It almost seems that this problem was introduced with the latest shibby build 115.

    I used the AC branch and I wonder, (before fiddling with iptables, which is an area I clearly don't understand), if I shouldn't try the 115 RT branch first, or install 114.

    But I guess the only one who could answer this is Shibby.

    @darkknight83, since when did you have to use these extra scripts?
     
    Last edited: Jan 5, 2014
  7. darkknight93

    darkknight93 Networkin' Nut Member

    Since v112 I think
     
  8. Powerkraut

    Powerkraut Reformed Router Member

    I see. Has anyone brought this to Shibby's attention? Or is her reading this forum anyway?
     
  9. koitsu

    koitsu Network Guru Member

    Shibby reads the forum actively when he has time. He has a real job and real life things that take precedence. Please respect that (I don't mean to sound rude or harsh, honest).
     
  10. Powerkraut

    Powerkraut Reformed Router Member

    No offense taken :)
     

Share This Page