Topic: Nortel Networks VPN Client and SME5 :(

[BEAN]

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

[Bryan]

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.

[Dan G.]

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

[Bryan]

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.

[Dan G.]

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

[BEAN]

Oh well I really liked SME to!!!

[Dan G.]

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

[BEAN]

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.

[Dan G.]

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

[BEAN]

Thanks Dan G.

[Bryan]

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.

[BEAN]

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

[Ray Dias]

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

[BEAN]

Do you know if you are using AH protocol (51/ip).

[Trevor B]

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.

[Trevor B]

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.

[BEAN]

WOW it worked thanks Trevor B.

[Dan G.]

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

[Bryan]

That did it!  Trevor, Dan, and Richie - thanks for all of your help!

[Ritchie Logan]

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

[JD]

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

[Francis]

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

[JD]

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