Changing the MTU on a PIX

Hey All,

I was wondering if anyone could help me out with this question.

If I change the MTU on my PIX to a lower number, does this change take effect once I save it or do I have to reboot the PIX.

I'm having some issues trying to connect to a clients Citrix server that is behind a Checkpoint Firewall. I am behind a PIX v6.2(2) and using the SecuRemote client to connect to our clients Checkpoint Firewall, then trying to open a Citrix connection. Unfortunately we are unable to successfully connect to their Citrix server. I am however able to Ping the Citrix server successfully. Any ideas on this would be MOST appreciated.

TIA

Random thought 1) Citrix usually uses tcp/1494 and udp/1604. Make sure you allow both (if not on a VPN connection)

Random thought 2) What is making you want to change your MTU? Sorry not sure if it requires a reboot or not, sorry. MIght want to shutdown the interface and then bring it back up to force it to relink, which may avoid a reboot, but if in doubt, I have always rebooted...*shrug*

Random thought 3) Are you running an access-list or are you just relying on interface number? Your inside interface is higher a number than the outside, right?

Random thought 4) If you are using secuRemote, I am assuming that means you are VPN'n. Are you sure that your VPN is working correctly? Depending on what protocol you are setup to use, you might have to allow that protocol back in (for example, protocol 50 and udp/500), which means you would have to add it into an access-list ...

Random thought 5) Are you vpn'nd in when you have pinged the citrix server? Does the site you are connecting through allow in ICMP from the gateway (another way in other than VPN).

Random thought 6) Have you tried a packet debug on your pix to see what the traffic is doing?
conf t
[no] debug packet <if_name> [src <s_ip> [netmask <m>]]
[dst <d_ip> [netmask <m>]]
[[proto icmp]|[proto tcp [sport <s_p>] [dport <d_p>]]
|[proto udp [sport <s_p>] [dport d_p]] [rx|tx|both]
(ie: debug packet outside src <your_ip> dst <citrix_ip>
debug packet outside src <citrix_ip> dst <your_ip>
)

If you are seeing your VPN traffic...turn off the debug on the outside interface and check the inside interface...That should tell you if a) if your traffic is making it out over vpn b) if you are receiving a response to your traffic c) if that return traffic is making it through your pix. Before you do that, make sure you have a large scroll back buffer, those packet debugs are verbose.


Hope that starts you in the right direction...

/nebulus

Quote:

---

Originally posted here by nebulus200
Random thought 4) If you are using secuRemote, I am assuming that means you are VPN'n. Are you sure that your VPN is working correctly? Depending on what protocol you are setup to use, you might have to allow that protocol back in (for example, protocol 50 and udp/500), which means you would have to add it into an access-list ...
/nebulus

---

I think neb is heading in the right direction. If the SecuRemote VPN is using IKE, then you have to allow udp-500 to pass through your firewall, as well as IP protocols 50 and 51 for AH and ESP. NOTE: these are not ports, they are protocols, but I believe the PIX will recognize them as ESP and AH as the service defined in your ACL.

Also, if you are using a many-to-one NAT or PAT on your firewall or router (which you probably are) you need to make sure you have support for UDP encapsulation on the VPN config, or you will have issues.

Good Luck

Great suggestions guys.

I have a few others for you.

1) If you are using IPSec and NAT, then AH will not be needed. You can't authenticate against a header that has been NATed. As far as ESP Proto 50, be sure that the firewall allows bi-directional traversal otherwise you are done.

2) If you are using NAT and IPSec, be sure that the Citrix box and/or the routers have a route set to the NAT pool. I see this issue all the time with VPNs that use NAT and IPSec.

3) Instead of changing the MTU on your firewall, why dont you try using a tool called Dr. TCP (found on the Cisco site or through a google search). It allows you to set the MTU on the PCs and the tool is VERY easy to use. Try setting MTU size to 1494 from 1500. This should make your IPSec tunnel *much* happier. If you can't find it, PM me and I will e-mail you a copy or post it here if the demand is high enough)

Anyway, give these things a look and see if they pan out.

Hope this helps

--TH13

I appreciate all the suggestions very much. As of this very morning I was vindicated.

I have thought this to be an issue with our clients network, but they and a vendor of theirs have been saying that this issue is being caused by a misconfig on my network. As I mentioned we are behind a PIX and trying to open a SecuRemote VPN connection to our clients network, then open a Citrix connection to one of their servers. I am able to authenticate properly to their VPN and am able to Ping their Citrix server, however, when I try to open a Citrix connection the connection times out. I do not see any "deny" or "no translation" errors in my logs from their IP. I asked their admin to check his logs and he says that he sees the VPN, ICMP traffic coming into their network and the return traffic leaving his network going back to mine. He also sees the Citrix traffic coming into his network to his Citrix server from our network, yet he never sees any return Citrix traffic from his Citrix server leave his network going back to my network. I have tried connecting from numerous configs. 1)machine using NAT, 2)machine using static NAT, 3)machine in DMZ which uses live IPs, so there is no NAT, with each of these configs I have tried opening all ports TCP, UDP, IP with no luck. This client is also using that proprietary Checkpoint protocol FWZ rather than a more standard one like IPSEC, so its not using port 50 and UDP 500.

Please correct me if I'm wrong on this...since their admin never sees the return Citrix traffic leave his network, how could that be an issue with my config? I could agree with that if the return Citrix traffic actually made it out of his network, but since it doesn't I don't see how that could be an issue with my config?

Again I really appreciate the help

oh btw- I confirmed that the PIX MTU change takes effect immediately once saved, so no reboot it required. The reason for the MTU change was that Citrix is known to having MTU issues.

If the traffic does not come back out of his network then investigate routing issues on *his* end, not youts.

OK: 1) Did you do the packet debug? Do you see your traffic leaving your network? Do you see a response to that traffic?

If I had to guess, I would say that your VPN is probably working right, and that you will see traffic leaving your network, but that you will not see the return traffic (for citrix only). What this indicates to me is that they may have a rule that is interfering with the two ports I mentioned earlier on their end (tcp/1494, udp/1604). If you want to test it outside of the citrix program, just use telnet once you are connected (telnet <hostname> 1494, if you are on unix, if not download a client other than the windows telnet client and specify the port as 1494). Try to connect to tcp/1494 (just 1494, it will default to tcp). If you get a connected message, you are getting there, there is some kind of citrix issue...

If you get no answer, then you are not getting there and I would strongly suspect they have some kind of a rule that is interfering with the return traffic...

Good luck!

/nebulus

Ahhh...FWZ huh? It will not work with hide NAT. I have had lots of bad experiences in the past because of FWZ. I would be willing to bet that is your problem. In order to verify this, you could try moving the SecuRemote host outside the firewall temporarily, or try with any non-firewalled setup (dialup?) as long as there is no NAT.

Lots of info can be found here:

http://www.phoneboy.com/fom-serve/cache/89.html

"HIDE NAT will only work correctly with IKE (it does not work with FWZ), provided the following is true:
UDP port 500 on your NAT gateway should be mapped to the SecuRemote client. FireWall-1 tries to communicate via this port.
Make sure your NAT gateway can pass IPSEC traffic (IP Protocol 50) if UDP Encapsulation is not used.
If UDP Encapsulation Mode is used, make sure it can pass UDP Port 2746.
If Gateway Clusters is used with UDP Encapsulation, you will need to upgrade to FireWall-1 4.1 SP3 or later for this to work correctly
Make sure that each HIDE NAT client is using a different IP address. If two clients attempt to use SecuRemote and have the same non-routable address, neither client will be able to access the internal network correctly. Where this will commonly show up is if two or more clients use the same NAT router with the default configuration. If you use Office Mode in NG FP1 and above, this limitation does not apply.
Make sure that ESP mode is configured for the affected users in their IKE Properties, encryption tab. AH will not work. This is generally the default.
The users home network cannot use the same IP address space as your encryption domain. For example, if the encryption domain includes 192.168.1.x, then the client's home network must use a different network. If you use Office Mode in NG FP1 and above, this limitation does not apply."

Quote:

---

Originally posted here by ol' jeb
If I change the MTU on my PIX to a lower number, does this change take effect once I save it or do I have to reboot the PIX.

---

If you conf t and made your changes you press ^Z to get out of the config.
Your changes will be made in the running config so yes changes take effect immediately and get lost as soon as you reboot. To make changes permanent you have to write mem.

Do u have any IPsec tunneling? That's not compatible with NAT.

Did u finally tried to get the MTU lower (around 1460 bytes), I guess u thought about it becoz of the tunnel encapsulation. I'm not sure you should do it at the PIX level, I'd rather do it into the local ACCESS router to spread to client the proper MTU or configure directly clients.
That will avoid frags in ur net.