How To Run Windows Vpn Thru Freesco 0.3.8.

Support section for FREESCO v0.3.x

Postby ken-neptune » Fri Jan 16, 2009 8:08 am

Lightning wrote: You will never see these options as modules because they are now built into the kernel and not included as modules.

Lightning,

Thanks for that clarification, I had a sneaky suspicion that something like that might be afoot, mostly because, otherwise such a lack would have been obvious in any submitted reports, and, you'd have noticed it well before now :lol:.

TTFN,
Ken
User avatar
ken-neptune
Newbie
 
Posts: 7
Joined: Sat Oct 04, 2008 11:00 am
Location: Blackburn, UK

Postby dingetje » Fri Jan 16, 2009 10:26 am

Just to be thorough (and because I understand the reasoning tongue.gif) I tried your suggestion of copy and paste for the suggested command, did it through Putty this time as well (just for a change), however, the beasts output was the same, I've only just really migrated to 0.4.0, but, did try the grep thing on 0.3.8 as well beforehand and unfortunately got the same error.


Strange, it appears grep does no longer support the -i switch? Anyway, the -i switch is to make the search case insenstitive, but because case sensitivity is not really an issue here you can try this command:

Code: Select all
grep masq /proc/ksyms
GreetZ
http://dingetje.homeip.net

"Software is like sex: it's better when it's free." - LINUS TORVALDS
User avatar
dingetje
FREESCO GURU !!
 
Posts: 1004
Joined: Wed Nov 14, 2001 12:13 pm
Location: The Netherlands

Postby ken-neptune » Fri Jan 16, 2009 11:23 am

dingetje wrote:Strange, it appears grep does no longer support the -i switch? Anyway, the -i switch is to make the search case insenstitive, but because case sensitivity is not really an issue here you can try this command:

Code: Select all
grep masq /proc/ksyms

Hi,

Thanks for the reply, I wouldn't have even close to thinking of dispensing with the -i, how on earth can you possibly keep all those commands, etc., in your head? Sometimes just pointing and clicking is difficult enough ..... :D

Anyhow the computer says :-

[root@Gateway] grep masq /proc/ksyms
0015f410 register_ip_masq_app
0015f474 unregister_ip_masq_app
0015fb98 ip_masq_skb_replace
0015ba7c ip_masq_out_get_ipsec
0015b77c ip_masq_in_get_ipsec
0015bb00 ip_masq_out_get_isakmp
0015b854 ip_masq_in_get_isakmp
0015cb78 ip_fw_masq_esp
0015d220 ip_fw_demasq_esp
0015c488 ip_fw_masq_gre
0015c738 ip_fw_demasq_gre
0015c7b8 ip_masq_pptp
0015c1c8 ip_masq_new
0015c3e8 ip_masq_set_expire
001d290c ip_masq_free_ports
001d2990 ip_masq_expire
0015b480 ip_masq_hash
0015b538 ip_masq_unhash
0015b978 ip_masq_out_get_2

Which, from your previous posting is afaik how it should be, does this help or create even more mystery.

BTW: I've no other users setup, hence very naughtily using root :o

Ta ta for now,
KP
User avatar
ken-neptune
Newbie
 
Posts: 7
Joined: Sat Oct 04, 2008 11:00 am
Location: Blackburn, UK

Postby dingetje » Fri Jan 16, 2009 12:27 pm

Thanks for the quick update.

how on earth can you possibly keep all those commands, etc., in your head?


Its a curse and a burden ;)

does this help or create even more mystery.


As said in my earlier post, this rules out kernel problems. Your kernel is fully patched.
GreetZ
http://dingetje.homeip.net

"Software is like sex: it's better when it's free." - LINUS TORVALDS
User avatar
dingetje
FREESCO GURU !!
 
Posts: 1004
Joined: Wed Nov 14, 2001 12:13 pm
Location: The Netherlands

Postby Lightning » Sat Jan 17, 2009 12:43 am

I have done some additional research on this specific problem and here is something to try and see if it works. Do the following
cd /boot/bin
snarf  <a href='http://lewys-spot.dyndns.org/packages/0.3.x/non-package/ipfwd.gz' target='_blank'>http://lewys-spot.dyndns.org/packages/0.3....ackage/ipfwd.gz</a>
zcat  <ipfwd.gz > ipfwd
rm ipfwd.gz
chmod +x ipfwd
cd /
edit  /rc/rc_user
Code: Select all
# xx.xx.xx.xx is the IP of your internal VPN server
firewall)
   ipfwadm -F -a accept -m -S xx.xx.xx.xx -D 0/0
  ;;
start)
    ipfwd --masq xx.xx.xx.xx 47  &
 ;;
stop)
   killall ipfwd
 ;;

Next you need to setup a single port forward on TCP port 1723 using the setup or the control panel. The manual to do this would be
edit /etc/portfw.cfg
Code: Select all
tcp,1723,1723,xx.xx.xx.xx
cp /etc/portfw.cfg /boot/etc/

At this point everything just needs to be started.
rc_pfwd  restart
rc_user  restart
rc_masq restart

The above is directly from the ipfwd readme file on to how to make a VPN server run behind a NAT router.
If you are afraid that you might make a mistake. The chances are high that you will never learn anything.
User avatar
Lightning
FREESCO GOD !!
 
Posts: 3046
Joined: Wed Nov 14, 2001 6:50 am
Location: Oregon, USA

Postby ken-neptune » Sun Jan 18, 2009 10:35 am

Lightning,


Thanks for the advice, which I tried to diligently follow,
the main exception being getting ipfwd; is the suggested version different? There doesn't seem to be an equivalent in the 0.4.0 repository for Freesco 0.4.0, however, based on the following, it's already present?

BTW, I'm not hugely bothered about showing IP addresses (probably should be though :rolleyes:) .

my rc_user file:-
Code: Select all
start) fn $0 $1 $SR
ipfwd -m 10.10.10.1 47 &
=
;;
stop) fn $0 $1 $ST

=
;;
restart) rc_user stop; rc_user start

;;
firewall) # ipfwadm -I -i deny -P tcp -W $INET -D 0/0 22 $LOG
ipfwadm -F -a accept -m -S 10.10.10.1 -D 0/0
      ;;
newip) # Execute commands after a new external IP



The beast wouldn't accept ipfwd --masq.

The resultant set of rules and forwards:-
Code: Select all
----- ipfwadm -F -lne -----
IP firewall forward rules, default policy: deny
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress       source               destination          ports
   77  9492 acc/m all  ---- 0xFF 0x00 *       0.0.0.0         10.10.10.1           0.0.0.0/0            n/a
    0     0 acc   all  ---- 0xFF 0x00 *       0.0.0.0         10.10.10.0/24        192.168.10.0/24      n/a
    0     0 acc   all  ---- 0xFF 0x00 *       0.0.0.0         192.168.10.0/24      10.10.10.0/24        n/a
 7352 7362K acc/m all  ---- 0xFF 0x00 eth0    0.0.0.0         10.10.10.0/24        0.0.0.0/0            n/a
    0     0 acc/m all  ---- 0xFF 0x00 eth0    0.0.0.0         192.168.10.0/24      0.0.0.0/0    

----- ipportfw -L -----
Prot Local Addr/Port > Remote Addr/Port                        
UDP 86.1.225.118/36220 > 10.10.10.1/36220                      
UDP 86.1.225.118/4500 > 10.10.10.1/4500                        
UDP 86.1.225.118/1701 > 10.10.10.1/1701                        
UDP 86.1.225.118/500 > 10.10.10.1/500                          
TCP 86.1.225.118/1723 > 10.10.10.1/1723                        
TCP 86.1.225.118/23 > 10.10.10.1/23      


I turned off PoPToP, tried an inbound remote PPTP access, sadly, it times out at verifying username and password.

Freesco logs :-
Code: Select all
an 18 15:10:47 - ipfwd[15014]: ipfwd version 1.0 startup: forwarding IP protocol 47 to 10.10.10.1. MASQ is ON, DEBUG is OFF.
Jan 18 15:11:17 - rc_masq: restart
Jan 18 15:11:17 - rc_masq: Ban external 60.18.168.108/32
Jan 18 15:14:47 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:14:47 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:14:47 - last message repeated 2 times
Jan 18 15:14:49 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:14:49 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:14:49 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:14:52 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:14:52 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:14:52 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:14:56 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:14:56 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:14:56 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:00 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:15:00 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:00 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:04 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:15:04 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:04 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:08 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:15:08 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:08 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:12 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:15:12 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:12 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:16 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:15:16 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:16 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.
Jan 18 15:15:20 - ipfwd[15014]: forwarding ip proto 47 from 217.34.39.186 to 10.10.10.1
Jan 18 15:15:20 - kernel: ip_fw_masq_gre(): Outbound GRE to 217.34.39.186 has no masq table entry.


Can I scream yet?

TTFN,
Ken P.
User avatar
ken-neptune
Newbie
 
Posts: 7
Joined: Sat Oct 04, 2008 11:00 am
Location: Blackburn, UK

Postby markmcjr » Thu Feb 12, 2009 12:17 am

Anyone had luck with this? I also have a SBS server behind Freesco 0.3.8 that I need to access via VPN. I was sad to see this discussion end without a stated resolution. Please help.
<br>Regards,<br>Mark<br><br><span style='color:purple'>-------------------------<br>www.mytruetech.com<br><br>Great technology makes people successful; Great people make technology successful. - MM</span>
User avatar
markmcjr
Newbie
 
Posts: 23
Joined: Sat Aug 03, 2002 3:41 pm

Postby Lightning » Thu Feb 12, 2009 5:17 am

Unfortunately I understand the problem. However the solution is going to require some extensive research into the kernel code. What has happened is that the kernel has been patched to allow VPN connections to be masqueraded so that multiple clients can connect externally to outside VPN servers. But the result of doing that has made protocol 47 have a masq table entry. But the protocol forwarder ipfwd is being intercepted on it's return somehow because of that and now the with the lack of a masq table entry because of ipfwd it can not be returned outbound from an internal server. It is possible that this problem can be overcome with some changes in the firewall rules. But it is going to require some experimenting and testing and at this moment I do not have the time to create a testing environment to do it.
If you are afraid that you might make a mistake. The chances are high that you will never learn anything.
User avatar
Lightning
FREESCO GOD !!
 
Posts: 3046
Joined: Wed Nov 14, 2001 6:50 am
Location: Oregon, USA

Postby markmcjr » Sun Feb 15, 2009 11:17 pm

I tried PoPToP and it is working great as a work-around.
<br>Regards,<br>Mark<br><br><span style='color:purple'>-------------------------<br>www.mytruetech.com<br><br>Great technology makes people successful; Great people make technology successful. - MM</span>
User avatar
markmcjr
Newbie
 
Posts: 23
Joined: Sat Aug 03, 2002 3:41 pm

Postby Lightning » Sun Feb 22, 2009 6:13 am

I have been considering this problem for some time and I am wondering if there is anyone who is willing to try some extra firewall rules to work around this issue. In the above logs the internal VPN server is at 10.10.10.1. Which in theory the only reason the replies are not going outbound is because they are trying to be masqueraded. Except looking at the ipfwd source code I think that the header would have already been rewritten and therefor it might not need to be masqueraded a second time. So what I propose is to add this rule into the rc_user file.
edit  /rc/rc_user
Code: Select all
firewall)
   ipfwadm -F -a accept -P gre -S 10.0.0.1
  ;;
start)
   fn $0 $1 $SR
   ipfwd -m 10.10.10.1 47 &
   =
;;

rc_masq restart


Of course there is a high probability that the gre protocol is not well enough defined in the kernel for this to work, but it is worth a try. Of course there could still be variants of this rule that still could make it possible, but the above would be the best. Of course also keep in mind that I don't remember when I added the gre protocol into the ipfwadm command and the above command may only work in the 04x series.
If you are afraid that you might make a mistake. The chances are high that you will never learn anything.
User avatar
Lightning
FREESCO GOD !!
 
Posts: 3046
Joined: Wed Nov 14, 2001 6:50 am
Location: Oregon, USA

Postby WildRat » Tue Mar 17, 2009 2:25 pm

This isn't solve the problem. I try 0.4.1 (kernel-040.586-vipc-cd-triton-power_off) and 0.4.2 (default kernel) unfortunately connection stops at password and username verifying. :( Connection from freesco lan to outside computer works.
User avatar
WildRat
Newbie
 
Posts: 7
Joined: Sun Jan 25, 2009 7:45 am

Postby Lightning » Tue Mar 17, 2009 10:08 pm

Thanks for giving it a try, do you have the logs from the connection attempt ?
If you are afraid that you might make a mistake. The chances are high that you will never learn anything.
User avatar
Lightning
FREESCO GOD !!
 
Posts: 3046
Joined: Wed Nov 14, 2001 6:50 am
Location: Oregon, USA

Postby WildRat » Wed Mar 18, 2009 1:04 pm

Full log attached as log2.txt
I got strange thing when i connect from freesco lan 192.168.1.10 to external station 10.18.0.111 and after that once again try to connect 192.168.1.10 all works good :wacko:
User avatar
WildRat
Newbie
 
Posts: 7
Joined: Sun Jan 25, 2009 7:45 am

Postby djricky » Thu May 21, 2009 10:20 am

Hi,

Any news about this problem?

Bye!
User avatar
djricky
Newbie
 
Posts: 11
Joined: Fri Mar 13, 2009 1:03 pm

Postby Lightning » Sat May 23, 2009 10:57 am

Any news about this problem?

Not yet, this is a kernel issue that will need some extended effort to resolve.
If you are afraid that you might make a mistake. The chances are high that you will never learn anything.
User avatar
Lightning
FREESCO GOD !!
 
Posts: 3046
Joined: Wed Nov 14, 2001 6:50 am
Location: Oregon, USA

PreviousNext

Return to FREESCO Support for v0.3.x

Who is online

Users browsing this forum: No registered users and 1 guest