This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

no networkt when pptp is active

Hi all!
I just wanted to test PPTP access and noticed, when a pptp connection is active, i can't access neither the firewall nor any of it's attached networks.
Has this also to do with the kerner nat module issue or is it a missconfiguration of my astaro? (Haven't installed the patch yet, cause connecting to my astaro as a pptp server seems to work just fine.)

Here's some more information about my system/setup:
  • Astaro 4.015, 3 NICs (WAN, LAN & WLAN)
  • added users for pptp connections with LAN subnet IPs
  • users can connect to my astaro via pptp and ping computer in my LAN
  • what further information do you need? 
[/list]

Thanks a lot in advance.
Best regards.
 Chris   


This thread was automatically locked due to age.
  • do you have packet filter rules setup to allow the access you are trying to use? 
  • Hi uncue!
    I don't filter any traffic from LAN to WAN. When there's no pptp connection active everything woks just fine.
    When there is a pptp connection i can ping the host that is connected via pptp, but not my firwall or any network behind it.
    Regards.
     Chris 
  • If you are assigning your pptp clients address to from the pptp-pool, you will need to set up a rule that allows the clients in the pptp-rule to get to whatever they are trying to do.  

    this is how it's done by default.


    If however you changed your pptp address to get an address the the LAN, it should work. 
  • I faced a similar issue, only it was the lack of a routing table rule that redirected traffic properly, everything was set to go through the tunnel because that's how pptp works.

    I created a route client side that says "Anything destined for 192.168.2.0 uses gateway 192.168.3.2 (pptp client IP)." Prior to this, everything was trying to go through the pptp tunnel first. 

    This is directly affected by an option in the pptp config "Use remote gw as default". Turning that option on, allowed data through the pptp tunnel but not out to the net (broken implementation?) and off, it would allow all traffic to the net, and is supposed to catch traffic destined for the remote end of the tunnel and redirect. The caveat here is the fact that my remote LAN is a 192.168.2, and the pptp-pool is a .3, hence the route. "Use default GW unless it goes to 192.168.2.0, for 192.168.2.0 it goes through 192.168.3.2)"

    This works perfectly for me.

    Also make sure you have rules open for the pptp connections, it doesn't do auto-magic iptables rules for you like ipsec does.

    This is only required if the lan you want to contact is on a different subnet than your pptp-pool.

    Reply with your ip pool configs - this may or may not be the case for you.
           
  • Hmmm ... I think you missunderstood me a little.
    The pptp clients can access the WAN just fine when they "dial in".
    But my "normal" hosts in the LAN subnet can't access the WAN as long as a pptp client is connected. When it disconnets, everything is fine again ...
    But thanks for you help till here anyway. [:)]
    Regards.
     Chris  
  • oops.  sorry.  I did misunderstand you.

    Unfortunately, I don't know enough about PPTP to help you, but I'm sure someone else here does. 
  • The next thing needed would be your network numberings; sanitize your Internet ones. Symptomatically, what you describe sounds like an IP routing overlap...
      
  • Hi SecApp!
    Yeah ... that's exactly, what I had in mind. Here's some more detailed Information about my setup:

    o 3 NICs: 
    • WAN: 130.83.19.167/24
    • LAN: 192.168.1.254/24
    • WLAN: 192.168.1.254/24
    [/list]

    o NAT on WAN for LAN & WLAN

    o generell rules:
    • Any/Any -> WAN: drop
    • LAN/Any -> Any: allow
    • WLAN/Any -> Any: allow
    • (There're a few more rules 'cause I need some forewarded ports)
    [/list]

    o pptp users get a predefined IP from the LAN segment

    o routing table:
    Code:
    130.83.19.0/24 dev eth1  scope link 
    192.168.2.0/24 dev eth2  scope link 
    192.168.1.0/24 dev eth0  scope link 
    127.0.0.0/8 dev lo  scope link 
    default via 130.83.19.254 dev eth1 
    local 192.168.2.254 dev eth2  table local  proto kernel  scope host  src 192.168.2.254 
    broadcast 192.168.1.0 dev eth0  table local  proto kernel  scope link  src 192.168.1.254 
    broadcast 192.168.2.255 dev eth2  table local  proto kernel  scope link  src 192.168.2.254 
    broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
    broadcast 130.83.19.255 dev eth1  table local  proto kernel  scope link  src 130.83.19.167 
    local 192.168.1.254 dev eth0  table local  proto kernel  scope host  src 192.168.1.254 
    broadcast 192.168.2.0 dev eth2  table local  proto kernel  scope link  src 192.168.2.254 
    broadcast 192.168.1.255 dev eth0  table local  proto kernel  scope link  src 192.168.1.254 
    broadcast 130.83.19.0 dev eth1  table local  proto kernel  scope link  src 130.83.19.167 
    broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
    local 130.83.19.167 dev eth1  table local  proto kernel  scope host  src 130.83.19.167 
    local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
    local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 



    o no static routes defined

    Thanks in advance.
    Reguards
     Chris  
  • I'm missing something; why is LAN the same network number as WLAN??

    Maybe you mean to make a Network Group WLAN, comprised of LAN and PPTP-Pool?
  • o 3 NICs:

        * WAN: 130.83.19.167/24 - is eth1
        * LAN: 192.168.1.254/24 - is eth0
        * WLAN: 192.168.1.254/24 - is eth2 (s/1\.254/2\.254) ?

    ^--- You must mean wlan is 192.168.2.254/24 based on the routes you posted.

    Let's make things clear first, do they get LAN (192.168.1.0) addy's, or WLAN (192.168.2.0) addy's, because they are not the same subnets, nor does the above properly describe your subnets unless WLAN is .2.0 which changes things significantly.

    Is Astaro forwarding pptp auth to a RAS server inside your network? 

    I don't see a ppp0 interface in your route setup which leads me to believe either something is mis-configured, or you have another machine controlling pptp. (Astaro will do the pptp connection, as well as pass authentication data to an internal PDC you know.)