How To Run Windows Vpn Thru Freesco 0.3.8.

[ken-neptune]

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 .

TTFN,
Ken

[dingetje]

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


[ken-neptune]

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 .....

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

Ta ta for now,
KP

[dingetje]

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.

[Lightning]

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.

[ken-neptune]

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.

[markmcjr]

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.

[Lightning]

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.

[markmcjr]

I tried PoPToP and it is working great as a work-around.

[Lightning]

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.

[WildRat]

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.

[Lightning]

Thanks for giving it a try, do you have the logs from the connection attempt ?

[WildRat]

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:

[djricky]

Hi,

Any news about this problem?

Bye!

[Lightning]

Any news about this problem?

Not yet, this is a kernel issue that will need some extended effort to resolve.