Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 1525 views
  • Users 0 members are here
Options
Suggested
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

PPTP Astaro 5?

eDRoaCH
so ive reinstalled astaro 5 today (im getting to be a pro at it)
Trying desperately to get PPTP access working because i hope to have my palm conect and hotsync thru it when i go to japan in two months ^^

anyway i followed the downloadable doc as closely as possible, and added teh masquerade ive seen numerous times on this messageboard however it seems im just not getting a payload accross
the pptp logs just show constant echos, so while monitoring a friend thats testing 4 me i saw that the packet filtering livelog had interesting info
DROP: IN=ppp0 OUT=eth2 SRC=10.52.249.2 DST=66.ip.hidden.37 LEN=56 TOS=0x00 PREC=0x00 TTL=127 ID=3013 PROTO=UDP SPT=1026 DPT=53 LEN=36 

so my GUESS is its the GRE ive seen posted about, however i dont have a clue HOW to enable gre, the network definitions as well as the packet filtering rules only care about tcp/udp

also i need some advice knowing HOW to test it, should they be able to ping my 192.168.7.x addresses? obviously pinging just the outside address doesnt help anything

ive got very general firewall rules atm because i want to get this working then tighten down
1. internal->external  any
2. external -> internal DCC (port 59)
3. PPTP pool->internal  any
4. any->pptp pool any
i tried to forward port 47 for gre but i believe gre isnt that port its a protocol #

clients have always been able to authenticate however can do nothing afterwards, adn with this new instalation my friend can no longer conect to the net when he is conected to me

sorry to ramble- but im trying to be as complete as possible! thanks in advance for the help!


This thread was automatically locked due to age.
  • 0
    Hi eDRoaCH, 

    your problem is not the GRE problem.

    The Packet filter drop you listed is a DNS request coming from your pptp client with the IP 10.52.249.2 and it wants to connect to 66.ip.hidden.37 through eth2.
    I am not quite sure which ip address that is.
    So at least you need to add a rule to enable this traffic.

    Please post your PPTP config, as i assume it has somethign todo with the DNS and so, plz also add a short description of your setup and the actual ruleset (filter/nat) you use.
    With all that we can easily find your problem.

    regards
    Gert
  • 0 in reply to Gert Hansen
    i just set up an extremly basic setup, no entries for dns or wins in the PPTP setup
    thats very interesting its a dns problem, im still unsure as to why my ruleset wouldnt allow dns
    trying to get this to work i  set up a dns and wins server on internal network (im mcse nt4 so i knew wins better, still not entirely sure if i have dns server right)
    im using the dns proxy with my internet and internal addresses there. im only listening on internal interface with any for allowed network so im guessing this is the problem
    since ive disabled zone transfers it should be safe to listen on external right?
    and they i give them the external ip as dns server?

    thx 4 the quick help!
  • 0
    so ive done some more configuration and testing, i added a firewall rule pptp-pool any any
    also added external to listening on dns proxy so client can surf web (does this open risk?)
    so i watched the livelog packetfilter while he connected, filtering only his external ip and got this (short session)

    2004:04:28-12:46:38 (none) kernel: DROP: IN=ppp0 OUT=eth2 SRC=10.52.249.3 DST=66.ip.hiden.37 LEN=57 TOS=0x00 PREC=0x00 TTL=127 ID=16727 PROTO=UDP SPT=1118 DPT=53 LEN=37 
    2004:04:28-12:46:38 (none) kernel: DROP: IN=ppp0 OUT= MAC= SRC=10.52.249.3 DST=255.255.255.255 LEN=96 TOS=0x00 PREC=0x00 TTL=128 ID=16729 PROTO=UDP SPT=137 DPT=137 LEN=76 
    2004:04:28-12:46:38 (none) kernel: DROP: IN=ppp0 OUT= MAC= SRC=10.52.249.3 DST=255.255.255.255 LEN=96 TOS=0x00 PREC=0x00 TTL=128 ID=16730 PROTO=UDP SPT=137 DPT=137 LEN=76 
    2004:04:28-12:46:39 (none) kernel: DROP: IN=ppp0 OUT=eth2 SRC=192.168.1.100 DST=217.255.142.44 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=16733 DF PROTO=TCP SPT=6881 DPT=25255 WINDOW=64240 RES=0x00 ACK URGP=0 
    2004:04:28-12:46:39 (none) kernel: ACCEPT: IN=eth0 OUT= MAC=00:00:e8:18:6a:f5:00:50:8d:f5:33:56:08:00 SRC=192.168.7.100 DST=192.168.7.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=20155 DF PROTO=TCP SPT=4985 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 

    no idea who that 217 addy is or why its there (considering i filtered by  66.ip.hiden.37) also i know broadcasts wont make it through
    my masq are  
    any->all all  masq_external    
    any->all all maq_internal
    i should mention my tester has a linksys but is configured in the dmz with both pptp and ipsec passthru enabled
  • 0 in reply to eDRoaCH
    for me it looks like your masquerading is set up wrong. i only have following config:
    Internal_Network__ -> All / All   MASQ__Internet

    You only need to translate outgoing traffic!
  • 0 in reply to ref
    hmm
    in my original setup i had no masq for the pptp but reading the boards several ppl sugested it

    any coments on the neccessity of it and how ecatally to set it up?
  • 0 in reply to eDRoaCH
    having a friend check my config he noticed my second masq has handled 0 packets so im guessing its either useles or configged wrong

    what seems to be happening is at least dns (which is pretty much all thats been tested) is being shot down when it gets sent from the pptp pool to the clients internet address

    still not sure why
  • 0 in reply to eDRoaCH
    packets from inside to internet need to have a translated source address, because the reserved ranges are not routed through internet. therefore your external ip has to be used and that is what masquerading is for. if you use pptp to connect to the firewall from internet, you have to make sure they get another subnet assigned as you use for your internal network. and you have to insert packet filters to allow traffic to pass. as soon as a pptp connection is up, you actually dont need masquerading, normal routing is more than sufficient.
  • 0 in reply to ref
    thanks for the clarification ref

    actually i finally found some1 with some network knowlege to test with me (the friend that was logging on and testing for me is a good guy with computers and programing but not a network guy)

    looks like i only have one problem 
    i need to fix my internal dns server, so its my fault afterall sorry to bug everyone

    thought i had it set up right but unfort when i got my training in nt4 dns was an afterthought to wins [:P]

    thanks to everyone that helped- when i get it workin i might post so ^^
Cookie Information Banner