Changing the MTU on a PIX
Results 1 to 10 of 10

Thread: Changing the MTU on a PIX

  1. #1
    Senior Member
    Join Date
    Jul 2002
    Posts
    106

    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
    just making some minor adjustments to your system....

  2. #2
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    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
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Posts
    458
    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

  4. #4
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,884
    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
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  5. #5
    Senior Member
    Join Date
    Jul 2002
    Posts
    106
    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.
    just making some minor adjustments to your system....

  6. #6
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,884
    If the traffic does not come back out of his network then investigate routing issues on *his* end, not youts.
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  7. #7
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    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
    There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.

    (Merovingian - Matrix Reloaded)

  8. #8
    Senior Member
    Join Date
    Jan 2002
    Posts
    458
    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."

  9. #9
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401

    Re: Changing the MTU on a PIX

    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.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  10. #10
    Senior Member
    Join Date
    Nov 2002
    Posts
    382
    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.
    [shadow] SHARING KNOWLEDGE[/shadow]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •