Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: BEAN on March 08, 2002, 04:14:48 AM
-
Ok......
I think I have tried everything I am trying to connect to my work with Nortel Networks VPN client through my SME5 server with no luck. I have connect my computer directly to the internet and successfully connected to my work. I have followed http://forums.contribs.org/index.php?topic=12107.msg45462#msg45462 instructions
ACCEPT udp ------ 0.0.0.0/0 68.39.131.101 500 -> 500
ACCEPT ipv6-crypt---0.0.0.0/0 68.39.131.101 n/a
and still I get the "Login Failure due to: Remote host not responding". In the nortel client I have disabled keepalives. I have done a fresh install of SME5 and applied the command and still no go.
This is what I get when I do /sbin/ipchains -L -n
Chain input (policy DENY):
target prot opt source destination ports
icmpIn icmp ------ 0.0.0.0/0 0.0.0.0/0 * -> *
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
denylog tcp ------ 0.0.0.0/0 0.0.0.0/0 0:19 -> *
denylog udp ------ 0.0.0.0/0 0.0.0.0/0 0:19 -> *
denylog tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 0:19
denylog udp ------ 0.0.0.0/0 0.0.0.0/0 * -> 0:19
DENY all ------ 224.0.0.0/4 0.0.0.0/0 n/a
DENY all ------ 0.0.0.0/0 224.0.0.0/4 n/a
ACCEPT tcp ------ 0.0.0.0/0 127.0.0.1 * -> 80
ACCEPT tcp ------ 0.0.0.0/0 192.168.43.1 * -> 80
ACCEPT tcp ------ 0.0.0.0/0 68.39.131.101 * -> 80
REDIRECT tcp ------ 192.168.43.0/24 0.0.0.0/0 * -> 80 => 3128
ACCEPT all ------ 192.168.43.0/24 0.0.0.0/0 n/a
ACCEPT tcp !y---- 0.0.0.0/0 0.0.0.0/0 * -> *
ACCEPT tcp ------ 0.0.0.0/0 68.39.131.101 * -> 113
ACCEPT udp ------ 0.0.0.0/0 68.39.131.101 * -> 113
ACCEPT udp ------ 0.0.0.0/0 0.0.0.0/0 * -> 67:68
ACCEPT udp ------ 0.0.0.0/0 0.0.0.0/0 67:68 -> *
ACCEPT tcp ------ 0.0.0.0/0 68.39.131.101 * -> 80
ACCEPT tcp ------ 0.0.0.0/0 68.39.131.101 * -> 443
ACCEPT ipv6-crypt------ 0.0.0.0/0 68.39.131.101 n/a
ACCEPT udp ------ 0.0.0.0/0 68.39.131.101 500 -> 500
ACCEPT gre ------ 0.0.0.0/0 68.39.131.101 n/a
ACCEPT tcp ------ 0.0.0.0/0 68.39.131.101 * -> 25
ACCEPT tcp ------ 0.0.0.0/0 68.39.131.101 * -> 22
denylog tcp -y---- 0.0.0.0/0 68.39.131.101 * -> 3306
DENY udp ------ 0.0.0.0/0 0.0.0.0/0 * -> 520
DENY tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 137:139
DENY udp ------ 0.0.0.0/0 0.0.0.0/0 * -> 137:139
denylog tcp -y---- 0.0.0.0/0 68.39.131.101 * -> 3128
ACCEPT tcp -y---- 0.0.0.0/0 68.39.131.101 20 -> 1024:65535
ACCEPT tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 1024:65535
ACCEPT udp ------ 0.0.0.0/0 0.0.0.0/0 * -> 1024:65535
denylog all ------ 0.0.0.0/0 0.0.0.0/0 n/a
Chain forward (policy DENY):
target prot opt source destination ports
ACCEPT all ------ 192.168.43.0/24 192.168.43.0/24 n/a
ACCEPT all ------ 192.168.43.0/24 192.168.43.0/24 n/a
MASQ all ------ 192.168.43.0/24 0.0.0.0/0 n/a
DENY all ------ 0.0.0.0/0 0.0.0.0/0 n/a
Chain output (policy ACCEPT):
target prot opt source destination ports
icmpOut icmp ------ 0.0.0.0/0 0.0.0.0/0 * -> *
- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 80
- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 22
- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 23
- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 21
- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 110
- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 25
- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 20
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
DENY all ------ 224.0.0.0/4 0.0.0.0/0 n/a
DENY all ------ 0.0.0.0/0 224.0.0.0/4 n/a
ACCEPT icmp ------ 192.168.43.0/24 0.0.0.0/0 * -> *
ACCEPT all ------ 0.0.0.0/0 192.168.43.0/24 n/a
ACCEPT tcp !y---- 68.39.131.101 0.0.0.0/0 80 -> *
ACCEPT tcp !y---- 68.39.131.101 0.0.0.0/0 443 -> *
ACCEPT tcp !y---- 68.39.131.101 0.0.0.0/0 25 -> *
ACCEPT tcp !y---- 68.39.131.101 0.0.0.0/0 22 -> *
ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a
Chain denylog (9 references):
target prot opt source destination ports
DENY all ------ 0.0.0.0/0 0.0.0.0/0 n/a
Chain icmpIn (1 references):
target prot opt source destination ports
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 0 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 3 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 4 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 11 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 12 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 8 -> *
denylog all ------ 0.0.0.0/0 0.0.0.0/0 n/a
Chain icmpOut (1 references):
target prot opt source destination ports
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 8 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 0 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 3 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 4 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 11 -> *
ACCEPT icmp ------ 0.0.0.0/0 0.0.0.0/0 12 -> *
denylog all ------ 0.0.0.0/0 0.0.0.0/0 n/a
-
Bean -
I've taken the same steps you describe and run into the same problem, with Nortel client and SME - same error. Please let me know if you solve the mystery.
-
Port forwarding UDP 500 to ONE static IP on your internal network may do the trick.
You already have the first part:
/sbin/ipchains --append input -p 50 -s 0/0 -d -j ACCEPT
/sbin/ipchains --append input -p udp -s 0/0 500 -d 500 -j ACCEPT
The second part (if you don't have it already) is download: http://www.myezserver.com/downloads/mitel/contrib/portforwarding-0.0.1/
and set it up. Then use it to push UDP 500 to the internal address of your choice. Verify with:
/usr/sbin/ipmasqadm portfw -n -l
Hope it works out for you,
Dan
-
Thanks for the suggestion, but this didn't do the trick for me. As I am relatively new to IP CHAINS, ideas for what to try next are hard to come by.
-
From the Linux VPN Masquerade FAQ:
"The IPsec AH protocol (51/ip) incorporates a cryptographic checksum including the IP addresses in the IP header. Since masquerading changes those IP addresses and since the cryptographic checksum cannot be recalculated by the masquerading firewall, the masqueraded packets will fail the checksum test and will be discarded by the remote IPsec gateway. Therefore, IPsec VPNs that use the AH protocol cannot be successfully masqueraded. Sorry. (ESP with authentication can be masqueraded.) "
If everything else has failed, it comes down to this. If this is the case, your only course of action is to speak with the administrator for the VPN gateway, and see if their policy and/or equipment can be modified to allow you to connect from behind NAT, but I'll bet $5 you're screwed. I just finished a MAJOR firewall installation for a client, using routable IP addresses behind a Red Hat 7.2 box running IPTables. Why? Because this client needs almost every host on his LAN able to connect with just about ANY brand of VPN appliance, in order to do business. IPChains/2.2 kernel is not up to the job for that kind of flexibility --- and the systems administrators at his client sites have been unwilling to modify policies to assist. Until I got this system in, they had been running TOTALLY without a firewall for nearly a year, because they couldn't find a system suitable. It's not an easy thing...
-
Oh well I really liked SME to!!!
-
Does your ISP offer the possiblity of multiple IP addresses? If you can get another IP, I have an elegant-yet-brute-force design that would allow you to keep that SME box, and use your VPN and your local network simultaneously. Otherwise, you'll need to setup the system running the VPN client with the primary IP assigned by your ISP, and run personal firewall software on it. Kinda sucks to have to keep switching cables and reconfiguring IP settings, but it's the sad reality...
-
Hey one more question I have read that a Linksys Cable DSL router supports IPsec AH protocol (51/ip) and that is using NAT why can't the SME foward AH protocol.
-
Apparently, Linksys and some other proprietary implementations have a way of performing the authentication with the gateway _on behalf of_ one NAT'd client. If I understand the protocol handling correctly, it knows how to spoof both the client and the gateway into a happy state. I think there may be a limitation in Linux kernel that prevents it from doing likewise.
Dan
-
Thanks Dan G.
-
Where did you read that the Linksys router would solve this problem? I looked on their website and they seem to confirm what Dan said earlier - that AH could not be routed period. I'm anxious not to trash SME, but I'll do so if the Linksys solution works.
-
Sorry you are correct I must have read an incorrect post. Linksys does not work with ah 51.
http://216.237.158.84/cgi-bin/om_isapi.dll?clientID=194116&QuestionText=ah%20ipsec%2051&SelectName1=&advquery=%5bs%5d%5bRank%2c%2050%3a%5bSum%3a%20ah%20ipsec%2051%5d%5bMerge%3a%20%5bThesaurus%3a%20ah%20ipsec%2051%5d%5d%5d&infobase=linksysrev.nfo&record={119}&softpage=IKW_ENU_JDocView
This sucks!!!!!!
-
I have Nortel working through my SME system ver. 5.0, and have been able to
do multiple session to my work. It has been a while, but i think what I did
was install the Freswan, ip_masq_vpn and the e-smith-ipsec rpm's. With these
rpm's installed, I have had up to 6 computers connected with the Nortel
Exranet Access Client for over 7 months. I have included the links to the
rpm's but there maybe new ones. If anyone needs further info, let me know
offline
I have also included the firewall rules that I have on my gateway
Ray Dias (ray at raydias dot net)
ftp://ftp.e-smith.org/pub/e-smith/contrib/AndreCouture/RPMS/noarch/
e-smith-vpn-0.1-2.noarch.rpm
ftp://ftp.e-smith.org/pub/e-smith/contrib/CharlieBrady/RPMS/
freeswan-1.9105.i586.rpm
ftp://ftp.e-smith.org/pub/e-smith/contrib/CharlieBrady/RPMS/
freeswan-1.91-05.i686.rpm
Chain input (policy DENY):
target prot opt source destination
ports
ACCEPT udp ------ anywhere anywhere 500 ->
any
ACCEPT ipv6-crypt ------ anywhere adsl n/a
Chain output (policy ACCEPT):
target prot opt source destination
ports
ACCEPT udp ------ adsl anywhere
500 -> any
ACCEPT ipv6-crypt ------ anywhere adsl n/a
ACCEPT ipv6-crypt ------ adsl anywhere n/a
-
Do you know if you are using AH protocol (51/ip).
-
Hi guys,
I too had the problem until I noticed the deliberate mistake in Ritchie's fix (thanks for pointing out the fix Ritchie - it was causing me some pain...)
The line
/sbin/e-smith/db configuration setprop masq ipseq yes
should be
/sbin/e-smith/db configuration setprop masq ipsec yes
so if you dis a cut-and-paste as I did, it didn't work. If you set ipsec to yes it is OK (well at least for me - I am using V03_70.30 of Nortel's Extranet Client).
Trevor B
P.S. I have also removed ALL of my custom tempaltes from the masq directory.
-
P.S. Don't forget to do the
/sbin/e-smith/signal-event remoteaccess-update
Trevor B wrote:
>
> Hi guys,
>
> I too had the problem until I noticed the deliberate mistake
> in Ritchie's fix (thanks for pointing out the fix Ritchie -
> it was causing me some pain...)
>
> The line
> /sbin/e-smith/db configuration setprop masq ipseq yes
>
> should be
> /sbin/e-smith/db configuration setprop masq ipsec yes
>
> so if you dis a cut-and-paste as I did, it didn't work. If
> you set ipsec to yes it is OK (well at least for me - I am
> using V03_70.30 of Nortel's Extranet Client).
>
> Trevor B
> P.S. I have also removed ALL of my custom tempaltes from the
> masq directory.
-
WOW it worked thanks Trevor B.
-
ooooookkkkkkayyyy....
So, this only leaves the question " are you using 51/ip AH, or not." The information is still confusing on this point.
I found one doc, dated sometime in 2000, stating that NAT/IPSec problems were "being fixed" --- so it would seem that two years later it could be fixed. Then, the Linux IPSec Masq FAQ states clearly that 51/ip still does not work. I'm inclined to believe this, but I see a lot of mixed info.
At any rate, I'm glad you got it to work. I have an SME gateway that my wife goes thru, using SecureRemote --- but it does not use 51/ip, only 50/ip and 500/udp. When she got a laptop, it brought up the need for a second passthru connection, but the SME box could not be forced to do that --- so I have another Linux box she uses as a gateway for the second connection.
Would it be possible to put tcpdump on your SME box, and see if it is passing 51/ip, or just 50/ip? That would be useful information.
Dan
-
That did it! Trevor, Dan, and Richie - thanks for all of your help!
-
wow.... praise and I didn't even take part in this discussion!!
Dan.... I know for sure that my Nortel client ONLY uses protocol 50, and UDP 500. I have also had e-smith masqing more than one connection at the same time.
Guys... apologies for the typo!!!!
Ritchie
-
The AH protocol will fail an IP checksum due to the packet being rewritten by the firewall as the packet gets NAT'd. If you
are using AH - the VPN tunnel will never be established.
I enable the ip_masq_ipsec.o module and did not have to
change any of the ipchains to get the EOC to build
and maintain IPSec tunnels (3DES with MD5 - not AH).
Worked well on dialup and now on DSL.
A 486 laptop SME private server supports multiple users each on their own EOC client PC. Using two 3Com PCMCIA NICs on 486
hardware with 24M.
Added the following to my /etc/rc.local file:
insmod /lib/modules/2.2.19-7.0.8/ipv4/ip_masq_ipsec.o
-
I tried this and the tunnel finally comes up but I cannot access anything on the other side. Did you make any other changes to IPChains from the default install ?
Francis....
-
No ... the EOC client was able to reach everything
once the IP_MASQ_IPSEC.O file was loaded.
Have you checked the IP address provided by the tunnel and the route table.
The nortel box I connect to does not use 'split tunnels' and the default router is through the tunnel. I am not able to access anything else except devices on the other side of the tunnel.
I did not have to touch the ipchains. But you could flush the input chain and change the policy to accept and retry.
>>JD<<