Outlook access over IPSEC VPN

[r-remien]

I have an IPSEC tunnel between a remote site (1720 with IOS Firewall v12.1(1)) and Corporate headquarters (PIX 515 v6.1.(1)) and it terminates on the Pix outside interface. Our Exchange 5.5 server is located on the inside LAN of the PIX. When email is sent to users on the other side of the tunnel at the remote site, there may be a 10 minute to one hour latency before their email arrives automatically. If they do a send/recieve, they can retrieve their all their email sent to date. Any ideas? I copied the config from the following URL and just changed the IP addresses and names of the crypto maps.

Configuring IPSec - Router to PIX

Using the nat 0 access-list Command

http://www.cisco.com/warp/public/110/39.html

[noc]

do you have a router @ HQ or is the PIX the DEFAULT GATEWAY of the EXCHANGE SERVER ?

[travis-dennis_2]

What client are they using? Outlook 2000 or XP? Is scheduled send and recieve turned off? That can cuase this behaviour if it is not.

[r-remien]

All clients are Outlook 2000. Also, the default gateway of the Exchange Server is a WAN router and the router's default gateway is the PIX.

Thanks,

RJ

[c.hope-lang]

Hi,

Did you get a fix for this as I am having the same problem??

[r-remien]

I have the resolution. The following ports are required for Exchange email to work through a firewall.

TCP port 135 - Allow client to come in via MSRPC

TCP port 139 - The netbios connection. This port is the connection that is maintained during the MAPI session. If you do a netstat -a -n, you will see that you have an "established" connection to IP of mail server:139 while Outlook is open.

UDP port 137 and port 138 - used by WINS and Exchange to allow updates of new changes. (Such as new email being sent to an Outlook client's inbox).

Also, there are 2 tcp ports in the range of 1024-65536 that are used to deliver mail back from the client.

I added this to my firewall and it worked.

access-list outbound permit udp host (IP address of Mail server) (subnet of other network on other side of tunnel) (subnet mask) eq 137

access-list outbound permit udp host (IP address of Mail server) (subnet of other network on other side of tunnel) (subnet mask) eq 138

Ex - access-list outbound permit udp host 10.1.1.1 192.168.1.0 255.255.255.0 eq 137

access-list outbound permit udp host 10.1.1.1 192.168.1.0 255.255.255.0 eq 138

10.1.1.1 - Exchange server

192.168.1.0/24 - Network that is not receiving automatic notification of email in their Inbox.

Let me know if it works.

Thanks,

RJ

[garytam]

Did this work for you?

I actually have a similar problem but it's between two exchange servers, each on different networks that are "bridged" via pix-to-pix vpn.

I was under the impression that if you configure the vpn access-list to allow "ip" between the two segments, then you would not have to create the more specific access-list that you've suggested. Also, the pix command "sysopt connection permit-ipsec" allows vpn traffic to bypass the access list applied to "outside."

I've seen documentation about your suggested access list applied to multiple exchange servers situated on different security levels of the pix but I wonder if it applies to hosts on two internal networks bridged together via VPN. Please let me know if it worked for you.

Thanks,

GT

[r-remien]

I am guessing that you you have 2 private ip schemes on either side of the tunnel and that there is no NAT across the tunnel that is protected by IPsec. Also, are your networks going across an Internet connection? Does the tunnel start and terminate on the outside interfaces of both pixes? If so, inbound traffic (that is not natted across the tunnel) will be allowed into each LAN without restrictions with "sysopt connection permit-ipsec". Although, in this configuration, outgoing traffic from each LAN is subject to an outbound access-list before it hits the IPsec tunnel (nonat access-list).

This is because the outbound access-list is bound to the inside interface and the access-list that controls the IPsec tunnel is bound to the outside interface. For example, Exchange A wants to send a UDP packet to a machine on the other side of the tunnel to notify the Inbox client that mail has arrived. The packet must pass an access-list check that is applied to the inside interface (such as udp 137 138) and then once it passes that check, the firewall will read the packet and check the IPsec tunnel access-list and see if it matches the destination subnet. This should work unless the crypto maps are not applied to the pix outside interfaces.

Hope this helps

RJ

[garytam]

Your guess is correct, I am using two private subnets on either side of the tunnel and the tunnel which does go thru the Internet terminates on the outside of both pixes. However, I don't have any restrictions (access-list) applied to traffic inbound to the inside int of either pix as both are trusted nets.

The problem I am seeing is intermittently there is only 1 rpc port being used between the two exchange servers and that is when communications between the two servers breaks down. Any ideas on what could be causing this problem?

Thanks,

GT

[r-remien]

You have an outbound list that is applied to the inside interface of the firewall. For the pix, all access-lists applied to interfaces (dmz1, dmz2, outside) are for incoming traffic through those interfaces from a lower to higher security level. The inside is the exception. The access-list applied to the inside interface is for outgoing traffic from your internal LAN. Make sure udp 137 138 are open and tcp ports above 1024 are open going out from the inside on both subnets. You need at least 2 of these ports greater than 1024 open. If you do not specify the tcp ports above 1024 in the registry on the Exchange servers, then you will need to allow all tcp ports above 1024 out on your access-list bound to the inside interface. You can turn on "logging trap debug" and look for ports denied by an access-list applied to your inside interface.

RJ

[mambojudi007]

hello r-remien

after your two commands in the pix:

access-list outbound permit udp host 10.1.1.1 192.168.1.0 255.255.255.0 eq 137

access-list outbound permit udp host 10.1.1.1 192.168.1.0 255.255.255.0 eq 138

should add another command ? as by example:

access-group outbound in interface outside or

access-group outbound in interface inside

our answer is very important for me

thanks

[a.karamanian]

Hello r-remien

The problem you are having with your exchange server is actually quite common. I will give you the solutions first then explain what is happening. There are two options:

1.option 1- turn off the DF-bit (do not fragment bit) on your exchange server by disabling path mtu discovery

2.option 2-

--- THIS WORKS WITH TUNNEL MODE AND NO GRE Remove the DF bit from the packet on the Pix and router before encryption

"crypto ipsec df-bit" should work here are some other suggestions:(http://www.cisco.com/en/US/products/sw/iosswrel/ps1833/products_feature_guide09186a008009c92c.html)

---WORKS FOR GRE INSIDE IPSEC Put a router between your exchange server and your pix, create a route map that turns off the DF bit and also do the same on the other router

example:

interface ethernet0

...

ip policy route-map clear-df

route-map clear-df permit 10

match ip address 101

set ip df 0

Why is the exchange server so slow ?

MS devices do a mtu path discovery once. If they get no reply via ICMP unreachable (Because the firewall drops ICMP or various other possible reasons) then it assumes all is good and will use the 1500 MTU of the local ethernet segment AND MICROSOFT PACKETS HAVE THE DF BIT ON BY DEFAULT. When it sends this packet over ipsec, ipsec adds a small overhead but enough to cause the packet to drop do to it now exceeding the 1500 mtu. Same thing will happen with stuff like ftp (large packet apps.)

Hope this helps =)

Andre Karamanian