PIX upgrade to 6.3?

Discussion in 'Cisco' started by David K, Dec 31, 2003.

  1. David K

    David K Guest

    I currently have multiple PIX 515's that I need to upgrade to v6.3 to
    allow Microsoft PPTP VPN access from internal PC's to a third party
    external network application. I'm currently running 6.2 and although
    I know that PPTP VPN (internal PC to external net) will work, it's not
    a clean solution for multiple FW's and users. The single "fixup
    protocol pptp 1723" command available in v6.3 looks to be best route
    for my situation. After perusing the Cisco PIX upgrade documents, the
    process appears to be fairly straightforward but I'm wondering if
    there are any caveats to performing the TFTP of the new bin file from
    a remote location? For example, I'm in Atlanta but need to upgrade a
    PIX in Chicago. I plan to connect from Atlanta to Chicago via W2K
    Terminal Server and then initiate the TFTP of the new BIN to the
    Chicago PIX from that W2K terminal server. Since I'm using the VPN
    channels created by both the Atlanta and Chicago PIX to connect to the
    Chicago network, will this process go smoothly? Also, there are
    currently two versions of 6.3 available, 6.3.1 and 6.3.3. No
    difference is mentioned and both are ED (Early Deployment) so I was
    planning on using 6.3.3. Thoughts, Ideas, Condolences? :)

    Best Regards,
     
    David K, Dec 31, 2003
    #1
    1. Advertising

  2. David K

    Wil Schultz Guest

    Well, you may want to use 6.3.3 as Cisco announced a vulnerability for
    6.3.1 and below. Something to the effect that if you have SNMP listening
    someone could through some SNMP v3 packets at it and crash it, why
    anyone would have their firewall listening to SNMP requests on the
    outside is beyond me, but... The TFTP 'should' go without a hitch. Make
    sure you have the correct requirement's and someone onsite at the remote
    with a console cable 'just in case' and you should be fine!

    Wil
    my 2¢
    "When everything seems to be going well, you have obviously overlooked
    something."


    David K wrote:
    > I currently have multiple PIX 515's that I need to upgrade to v6.3 to
    > allow Microsoft PPTP VPN access from internal PC's to a third party
    > external network application. I'm currently running 6.2 and although
    > I know that PPTP VPN (internal PC to external net) will work, it's not
    > a clean solution for multiple FW's and users. The single "fixup
    > protocol pptp 1723" command available in v6.3 looks to be best route
    > for my situation. After perusing the Cisco PIX upgrade documents, the
    > process appears to be fairly straightforward but I'm wondering if
    > there are any caveats to performing the TFTP of the new bin file from
    > a remote location? For example, I'm in Atlanta but need to upgrade a
    > PIX in Chicago. I plan to connect from Atlanta to Chicago via W2K
    > Terminal Server and then initiate the TFTP of the new BIN to the
    > Chicago PIX from that W2K terminal server. Since I'm using the VPN
    > channels created by both the Atlanta and Chicago PIX to connect to the
    > Chicago network, will this process go smoothly? Also, there are
    > currently two versions of 6.3 available, 6.3.1 and 6.3.3. No
    > difference is mentioned and both are ED (Early Deployment) so I was
    > planning on using 6.3.3. Thoughts, Ideas, Condolences? :)
    >
    > Best Regards,
     
    Wil Schultz, Dec 31, 2003
    #2
    1. Advertising

  3. In article <>,
    David K <> wrote:
    :I currently have multiple PIX 515's that I need to upgrade to v6.3

    :After perusing the Cisco PIX upgrade documents, the
    :process appears to be fairly straightforward but I'm wondering if
    :there are any caveats to performing the TFTP of the new bin file from
    :a remote location?

    Not really, the process is pretty smooth.

    : For example, I'm in Atlanta but need to upgrade a
    :pIX in Chicago. I plan to connect from Atlanta to Chicago via W2K
    :Terminal Server and then initiate the TFTP of the new BIN to the
    :Chicago PIX from that W2K terminal server. Since I'm using the VPN
    :channels created by both the Atlanta and Chicago PIX to connect to the
    :Chicago network, will this process go smoothly?

    It should. I've done something similar.

    Just remember to save off your configuration right before
    the upgrade and save off the configuration after rebooting
    after the upgrade; 6.3 introduces a few configuration changes
    that you will want to review by looking at the differences between
    the two save configurations.


    : Also, there are
    :currently two versions of 6.3 available, 6.3.1 and 6.3.3. No
    :difference is mentioned and both are ED (Early Deployment) so I was
    :planning on using 6.3.3.

    The release notes go into the details. For example, 6.3(3)
    introduces Policy Nat. And as the other poster mentioned,
    6.3(1) has a vulnerability.
    --
    Cannot open .signature: Permission denied
     
    Walter Roberson, Dec 31, 2003
    #3
  4. David K

    David K Guest

    Thanks for the feedback. I just performed (2) PIX 515 upgrades to
    version 6.3.3 from a remote location using TFTP and they both went
    perfectly. I added the "fixup protocol pptp 1723" command and tested
    the Microsoft VPN client and it also now works perfectly. wr mem and
    outta here for the weekend! :)

    Best Regards,




    -cnrc.gc.ca (Walter Roberson) wrote in message news:<bsv4rt$7pq$>...
    > In article <>,
    > David K <> wrote:
    > :I currently have multiple PIX 515's that I need to upgrade to v6.3
    >
    > :After perusing the Cisco PIX upgrade documents, the
    > :process appears to be fairly straightforward but I'm wondering if
    > :there are any caveats to performing the TFTP of the new bin file from
    > :a remote location?
    >
    > Not really, the process is pretty smooth.
    >
    > : For example, I'm in Atlanta but need to upgrade a
    > :pIX in Chicago. I plan to connect from Atlanta to Chicago via W2K
    > :Terminal Server and then initiate the TFTP of the new BIN to the
    > :Chicago PIX from that W2K terminal server. Since I'm using the VPN
    > :channels created by both the Atlanta and Chicago PIX to connect to the
    > :Chicago network, will this process go smoothly?
    >
    > It should. I've done something similar.
    >
    > Just remember to save off your configuration right before
    > the upgrade and save off the configuration after rebooting
    > after the upgrade; 6.3 introduces a few configuration changes
    > that you will want to review by looking at the differences between
    > the two save configurations.
    >
    >
    > : Also, there are
    > :currently two versions of 6.3 available, 6.3.1 and 6.3.3. No
    > :difference is mentioned and both are ED (Early Deployment) so I was
    > :planning on using 6.3.3.
    >
    > The release notes go into the details. For example, 6.3(3)
    > introduces Policy Nat. And as the other poster mentioned,
    > 6.3(1) has a vulnerability.
     
    David K, Jan 2, 2004
    #4
  5. David K

    Greg Reaume Guest

    "David K" <> wrote in message
    news:...
    > Thanks for the feedback. I just performed (2) PIX 515 upgrades to
    > version 6.3.3 from a remote location using TFTP and they both went
    > perfectly. I added the "fixup protocol pptp 1723" command and tested
    > the Microsoft VPN client and it also now works perfectly. wr mem and
    > outta here for the weekend! :)
    >


    It's good to hear at least one person had luck with this upgrade... :) I
    had nothing but trouble since I've gone to 6.3.x. I moved to 6.3.1 for the
    OSPF but kept running into bugs left, right, and centre. The eternal
    balance of features vs. stability I guess. :)

    Now I'm going to rant for the amusement of those who are interested...

    I went through a crippled stage, where we were unable to send e-mail to
    several domains (such as aol.com, us.ibm.com [although ca.ibm.com/ibm.com
    was fine], several subdomains of slb.com, ca.com, etc. After a long case
    and several engineers working on it at Cisco, it turns out in 6.3.x Cisco
    introduced a security 'feature' where the maximum length of a DNS reply
    packet was limited to 512bytes. Well it just so happens that each of these
    domains have so many MX records that their replies go over the limit.
    "Okay, easy enough...", I say, "I'll just shut the feature off." The reply:
    "we didn't include the capability to do that in 6.3.1." They had already
    identified it as an 'issue', which is also why it took them so long to match
    my problem to it because they didn't consider it as a bug so it wasn't in
    the tracker. :p They had included a command in 6.3.3 (fixup prot dns
    maximum-length xxx), but that release wasn't due out for several weeks at
    the time. As a workaround I ended up adding the zones to our internal DNS
    servers and authoritatively issued MX replies to my mail servers and limped
    along with HTTP sacrificed for those domains (mail was more important).

    6.3.3 comes out, I attempt the upgrade. Immediately noticeable is the
    malfunction of failover. Both PIX insisted they were active. So I shut one
    off, no big deal. Then I hear that VPNs aren't working. I pull up my
    syslog file to see what's wrong and guess what? Logs are empty. I check
    the buffered logs on the PIX, there are none. Roll-back!

    Once again, a case with TAC - same engineer I had for the last one! LOL
    After about two weeks, 3 engineers, two escalations, and 3-4 more upgrade
    attempts, and no progress, I decide to take this show into my own hands. I
    erase my config and go command by command until I find out what breaks it.
    Turns out it breaks when I set not one, but two NTP servers. Of course it
    would be something so frivolous as time sync that would bring my firewalls
    to their knees for two weeks. I report my findings to Cisco and they reply:
    "Oh, yes, there's a bug in our internal database that describes that
    behaviour; thanks. There's no fix yet. Is there anything else we can help
    you with before we close this case?". !@#$%@$#%K@#$%K!#$%!@#$%!!!!!!!!!!!!!
    ARGHHHhhhh!

    I'll stop now before I get blacklisted by TAC. ;)

    Happy upgrading!

    Greg
     
    Greg Reaume, Jan 3, 2004
    #5
  6. David K

    Rik Bain Guest

    On Sat, 03 Jan 2004 02:27:44 -0600, Greg Reaume wrote:

    > It's good to hear at least one person had luck with this upgrade... :)
    > I had nothing but trouble since I've gone to 6.3.x. I moved to 6.3.1
    > for the OSPF but kept running into bugs left, right, and centre. The
    > eternal balance of features vs. stability I guess. :)
    >
    > Now I'm going to rant for the amusement of those who are interested...
    >
    > I went through a crippled stage, where we were unable to send e-mail to
    > several domains (such as aol.com, us.ibm.com [although
    > ca.ibm.com/ibm.com was fine], several subdomains of slb.com, ca.com,
    > etc. After a long case and several engineers working on it at Cisco, it
    > turns out in 6.3.x Cisco introduced a security 'feature' where the
    > maximum length of a DNS reply packet was limited to 512bytes. Well it
    > just so happens that each of these domains have so many MX records that
    > their replies go over the limit. "Okay, easy enough...", I say, "I'll
    > just shut the feature off." The reply: "we didn't include the
    > capability to do that in 6.3.1." They had already identified it as an
    > 'issue', which is also why it took them so long to match my problem to
    > it because they didn't consider it as a bug so it wasn't in the tracker.
    > :p They had included a command in 6.3.3 (fixup prot dns maximum-length
    > xxx), but that release wasn't due out for several weeks at the time. As
    > a workaround I ended up adding the zones to our internal DNS servers and
    > authoritatively issued MX replies to my mail servers and limped along
    > with HTTP sacrificed for those domains (mail was more important).
    >
    > 6.3.3 comes out, I attempt the upgrade. Immediately noticeable is the
    > malfunction of failover. Both PIX insisted they were active. So I shut
    > one off, no big deal. Then I hear that VPNs aren't working. I pull up
    > my syslog file to see what's wrong and guess what? Logs are empty. I
    > check the buffered logs on the PIX, there are none. Roll-back!
    >
    > Once again, a case with TAC - same engineer I had for the last one! LOL
    > After about two weeks, 3 engineers, two escalations, and 3-4 more
    > upgrade attempts, and no progress, I decide to take this show into my
    > own hands. I erase my config and go command by command until I find out
    > what breaks it. Turns out it breaks when I set not one, but two NTP
    > servers. Of course it would be something so frivolous as time sync that
    > would bring my firewalls to their knees for two weeks. I report my
    > findings to Cisco and they reply: "Oh, yes, there's a bug in our
    > internal database that describes that behaviour; thanks. There's no fix
    > yet. Is there anything else we can help you with before we close this
    > case?". !@#$%@$#%K@#$%K!#$%!@#$%!!!!!!!!!!!!! ARGHHHhhhh!
    >
    > I'll stop now before I get blacklisted by TAC. ;)
    >
    > Happy upgrading!
    >
    > Greg


    I have seen all of the above first hand....But what do you expect from ED
    code? 6.3 was a big leap, cisco even introduced new features in a point
    release.

    Happy GD'ing :)
     
    Rik Bain, Jan 3, 2004
    #6
  7. David K

    Greg Reaume Guest

    "Rik Bain" <> wrote in message
    news:p...
    >
    > I have seen all of the above first hand....But what do you expect from ED
    > code? 6.3 was a big leap, cisco even introduced new features in a point
    > release.
    >


    :) I was fully aware of the risk I was taking with ED code, I was ranting
    more about Cisco's TAC and their inability to properly troubleshoot and use
    their own bug tracking system. What's more, to implement a feature that
    limits a packet length without first doing one minute of checking 'real'
    domains to see if that maximum was within standard operational parameters,
    and then not including any way to work-around it, is a little careless, even
    in ED code. Something that obvious should have been caught before it went
    public.

    I agree that 6.3 was a huge leap, I'm definitely glad to see the new
    features.

    Happy ED'ing (with care and patience). ;)

    Greg
     
    Greg Reaume, Jan 3, 2004
    #7
  8. David K

    Hansang Bae Guest

    In article <CqvJb.23431$>, greg@no-
    spam.reaume.name says...
    > :) I was fully aware of the risk I was taking with ED code, I was ranting
    > more about Cisco's TAC and their inability to properly troubleshoot and use
    > their own bug tracking system. What's more, to implement a feature that
    > limits a packet length without first doing one minute of checking 'real'
    > domains to see if that maximum was within standard operational parameters,
    > and then not including any way to work-around it, is a little careless, even
    > in ED code. Something that obvious should have been caught before it went
    > public.
    > I agree that 6.3 was a huge leap, I'm definitely glad to see the new
    > features.
    > Happy ED'ing (with care and patience). ;)


    There's been a general decline in the quality of software coming from
    Cisco. Granted, they have more legacy code to deal with (I don't see
    Juniper supporting X25, LAT, Decnet etc...all of which are in use at big
    financial corporations).

    But the new IOS seems really laden with bugs these days.


    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Jan 3, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Richard

    PIX to PIX to PIX meshed VPN

    Richard, Nov 13, 2003, in forum: Cisco
    Replies:
    1
    Views:
    643
    Richard
    Nov 15, 2003
  2. Remco Bressers
    Replies:
    1
    Views:
    555
    Jyri Korhonen
    Nov 21, 2003
  3. Bill F
    Replies:
    1
    Views:
    458
    Walter Roberson
    Nov 25, 2003
  4. shifty
    Replies:
    13
    Views:
    2,458
    shifty
    Dec 31, 2004
  5. Speed3ple
    Replies:
    0
    Views:
    3,064
    Speed3ple
    Apr 4, 2006
Loading...

Share This Page