Pix translation issue

Bl8ckr0uterBl8ckr0uter Inactive Imported Users Posts: 5,031 ■■■■■■■■□□
Ok guys guru I have a problem. I am trying to set up sonicwall netextender on a SSL 4200 with a pix 515 firewall. I have configured the SSL to a T but in the pix I keep getting this error:


106011: Deny inbound (No xlate) icmp src inside: internalserver dst inside:192.168.200.201 (type 0, code 0)
106011: Deny inbound (No xlate) icmp src inside:internalserver dst inside:192.168.200.201 (type 0, code 0)

192.168.200.X is the net extender range. I checked the nat config:

nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 10 192.168.200.0 255.255.255.0 0 0
nat (inside) 10 0.0.0.0 0.0.0.0 0 0
nat (dmz) 10 0.0.0.0 0.0.0.0 0 0


Everything looks good to me. I did added an entry on the access-list inside_outbound list for the 192.168.200.0 range bu it did not help. Anyone have any ideas?

Comments

  • AhriakinAhriakin SupremeNetworkOverlord Member Posts: 1,800 ■■■■■■■■□□
    What version are you running? If 7+ do you have nat-control enabled. Even if it's disabled check your globals. If there is a NAT statement that can cover the range of source IPs on the ingress int but no Global on the egress (or nat exemption, identity NAT etc.) it will still fail even with NAT-Control disabled.

    You have a NAT exemption ACL but are these flows covered by it (as in have you defined both source AND dest subnet(s), not just that subnet to any)?

    Also it looks like you are hairpinning traffic on the INSIDE (The message is from the INSIDE to a dst also routed back through that DMZ). Have you enabled Intra-interface same-security traffic, otherwise hairpinning will fail?

    Really we'd need the matching Globals, that NAT-0 ACL, your NAT-Control status and the routing involved to be sure where to start but the above covers the basics.
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
  • Bl8ckr0uterBl8ckr0uter Inactive Imported Users Posts: 5,031 ■■■■■■■■□□
    Ahriakin wrote: »
    What version are you running? If 7+ do you have nat-control enabled. Even if it's disabled check your globals. If there is a NAT statement that can cover the range of source IPs on the ingress int but no Global on the egress (or nat exemption, identity NAT etc.) it will still fail even with NAT-Control disabled.

    Pix os 6.2.
    Ahriakin wrote: »
    You have a NAT exemption ACL but are these flows covered by it (as in have you defined both source AND dest subnet(s), not just that subnet to any)?

    This is probably the problem. I know I have the source the but I don't think I defined the Lan subnet(s) as the destination. Would I need to define all of my lan subnets in a nat list? Could you give me an example of what one would look like?

    Ahriakin wrote: »

    Also it looks like you are hairpinning traffic on the INSIDE (The message is from the INSIDE to a dst also routed back through that DMZ). Have you enabled Intra-interface same-security traffic, otherwise hairpinning will fail?

    Really we'd need the matching Globals, that NAT-0 ACL, your NAT-Control status and the routing involved to be sure where to start but the above covers the basics.

    How do you enable intra-interface same-security traffic?


    I won't be able to get back to that box until Sunday but thanks for the advice!
  • Bl8ckr0uterBl8ckr0uter Inactive Imported Users Posts: 5,031 ■■■■■■■■□□
    ???????????


    WTF.......

    I am rereading the deployment docs on the SSL tonight.
  • AhriakinAhriakin SupremeNetworkOverlord Member Posts: 1,800 ■■■■■■■■□□
    Got to run to a meeting but basically:

    same-security-traffic permit intra-interface
    Allows traffic to hairpin on the same int.

    Offhand I'm not sure this is supported pre 7.x, I have a funny feeling it's not...actually pretty sure.


    For Nat exemption use an extended ACL, the resulting exemption is bidirectional (Not all NAT types are).

    e.g.
    access-list NONAT-INSIDE permit 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
    !
    nat (INSIDE) 0 access-list NONAT-INSIDE

    This sits at the top of the NAT heirarchy and overrides all other NAT types. (You can add denies earlier in the ACL if need be but try to avoid this, it gets messy but is sometimes needed to essentially exempt from the exemption :) )
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
Sign In or Register to comment.