1.8b Development

Just wondering if there is any features like these in the newer 499 version or the upcoming versions or settings in the current beta to try to do same things.....our market using this software which is hundreds requires these features by standards....also we have many 1.31 versions in field and have nor been able to upgrade to the 1.49 version, please help...thanks

Not sure what you mean by Auto IP and Auto VPN.

As to not being able to upgrade from 1.31 to 1.8.0b499, you don't say anything about which version of 1.31 you are using, or the hardware it is running on.

1.8.0b will not fit within a 16MB CF or DOM as commonly used on 1.3x embedded systems, 32MB minimum is now required. Also, 128MB of RAM is required for stable operation. Do your 1.31 systems meet these requirements for an embedded install? Are you following the upgrade instructions, including those in the "Other important points" section?

Sorry...1.31 loaded on generic pc, 2.8ghz processor, 1gb ram and using a IDE/CF powered adapter...as for Auto IP and Auto VPN, Auto IP is to allow any IP to get the CP page and use the network regardless of IP or proxy settings....Auto VPN feature is similar in that it allows any VPN client using their software thru the firewall directly and does not block any ports like the firewall normally does...in some cases gateways have a check box written in an HTML code upon CP startup and sign in that asks them if they wish to use a static IP from the WAN pool from the ISP to conduct their VPN....

hope that better explains....let me know.

thanks

I can speak to the Auto IP and Auto VPN features, sorry.

You didn't say how large your CF card is, but for 1.8.0b it needs to be at least 32MB.

oh sorry its 1gb and we also use 2gb CF cards....we have 1.31 running in the field we remote inot the gateways but cannot seem to upgrade them to the b versions....unsure what we are doing wrong.

Are you doing this step?

images cannot be uploaded directly to current 1.33 installations because the MFS that they allocate for firmware uploads is too small (only 10 MB). You can work around this by running the following commands via /exec.php after you've clicked the "Enable firmware upload" button:
            umount /ftmp
            /sbin/mdmfs -s 16m md1 /ftmp

"Auto VPN" as far as I know is just not doing any egress filtering. By default m0n0wall meets that requirement. I'm not aware of any VPN that requires anything more than that.

"Auto IP" is very unlikely to happen for this reason.
http://forum.m0n0.ch/index.php/topic,5469.0.html#msg16634

Monowall still has issues in our setups and applications with travelers that use our systems and their Cisco Ipsec VPN softwares trying to connect to their home office VPN hosts....does anyone know why? I have seen ports trying to be used like 4500 UDP as a reference....also we have all ports opened up in our firewall settings...what are we doing wrong here to get these people connected to their VPN hosts?

thanks....

Hi dr,
could you post the log entry when you try to do the VPN connection?
Jakob

jakob, we do not personally perform the VPN connections...our customers perform them. We will try to get a log entry and copy that ..we did find these entries though. Does this help?

20:11:29.900209 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.98,54224 PR udp len 20 176 IN bad NAT
20:11:29.486674 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.95,63771 PR udp len 20 208 IN bad NAT
20:11:29.069497 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.94,49839 PR udp len 20 160 IN bad NAT
20:11:28.560483 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.101,57874 PR udp len 20 240 IN bad NAT
20:11:28.070309 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.95,63771 PR udp len 20 224 IN bad NAT
20:11:27.904491 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.94,49839 PR udp len 20 208 IN bad NAT
20:11:27.498461 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.99,57831 PR udp len 20 176 IN bad NAT
20:11:27.079466 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.95,63771 PR udp len 20 224 IN bad NAT
20:11:27.010302 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.94,49839 PR udp len 20 208 IN bad NAT

20:11:29.900209 bge0 @200:65 b 12.1.83.251,4500 -> 172.20.1.98,54224 PR udp len 20 176 IN bad NAT

Please try again after disabling hardware checksumming using the following command on /exec.php for each interface (bge0 etc.):

ifconfig bge0 -rxcsum -txcsum
(this change will be lost on reboot)

I suspect that the problems with IPsec NAT-T passthrough (i.e. port 4500) have something to do with the way the built-in NAT-T support in FreeBSD works in conjunction with hardware checksumming on the NICs.

Manuel,
ifconfig vr0 -rxcsum -txcsum
ifconfig vr1 -rxcsum -txcsum
ifconfig vr2 -rxcsum -txcsum
works
jakob

Please try b500 - I think I've found and fixed the bug (in ipfilter kernel code).

Manuel, Tank you for fixing this so quickly. I tested it against a Juniper VPN Box. First Tests where positive. Which was not the case with b499 without ifconfig ..... commands
Jakob

Thank you Manuel....we are uploading b500 to our b499 PC boxes we have out in the field...I will let you know if this helps out the Ipsec VPN situation for the Walmart people who are traveling and using that VPN setup....

I do know they specifically complained about their microsoft exchange server not working to be able to get their emails...I assume that would directly relate to the VPN issue...right?

DR01