[c-nsp] how NAt works from outside to inside
s m
sam.gh1986 at gmail.com
Sun Mar 31 01:52:43 EDT 2013
thanks matt but i think you are misunderstanding. i want to nat inside IPs
and therefore pool should be defined in the rang of outside in order to nat
inside IPs to IPs in these range.
my configuration works when i ping from inside to outside and in reverse
side. i just don't understand how outside system identifies reply packets
that have nated source address while request packets are sent without any
nat translation.
for example these are a sample of packets that are send and receive from a
outside system:
request packets: src:192.168.2.1----> dst: 192.168.1.1
reply packets: src: 192.168.2.50----> dst:192.168.2.1
logically the outside system (192.168.1.1) should not recognize that reply
packets are belong to it (because src address in reply packet is different
from dst address in request packet), but it recognize and accepts reply
packets. how this happens???
On Sat, Mar 30, 2013 at 11:41 PM, Matt Thompson
<mthompson at brightsolid.com>wrote:
> You may have typed it up incorrectly but you appear to have applied the
> NAT pool to your internal interface, but the NAT pool belongs to the subnet
> on your outside interface. As you are using dynamic NAT, I am going to
> assume that you are wanting to NAT the internal IPs as they go externally
> so you need to change the NAT pool to be a 192.168.1.x range, assuming the
> interface NAT commands are correct, else, swap these interface NAT commands.
>
> Hope this is of help,
>
> Matt Thompsopn
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:
> cisco-nsp-bounces at puck.nether.net] On Behalf Of
> cisco-nsp-request at puck.nether.net
> Sent: 30 March 2013 16:21
> To: cisco-nsp at puck.nether.net
> Subject: cisco-nsp Digest, Vol 124, Issue 82
>
> Send cisco-nsp mailing list submissions to
> cisco-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> or, via email, send a message with subject or body 'help' to
> cisco-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
> cisco-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of cisco-nsp digest..."
>
>
> Today's Topics:
>
> 1. Re: Cisco and BGP MED (Harold Ritter (hritter))
> 2. Re: Cisco ASA static dhcp binding (Bruce Pinsky)
> 3. how NAt works from outside to inside (s m)
> 4. Re: community on bgp update (Oliver Boehmer (oboehmer))
> 5. Re: netflow with source-mac address? (Phil Mayers)
> 6. Re: netflow with source-mac address? (Gert Doering)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 29 Mar 2013 22:34:49 +0000
> From: "Harold Ritter (hritter)" <hritter at cisco.com>
> To: Brandon Ewing <nicotine at warningg.com>, "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Cisco and BGP MED
> Message-ID:
> <16365C0CD422BB4685B2080FAE12EF330C9ED13E at xmb-aln-x12.cisco.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Brandon,
>
> See comments inline.
>
>
>
> Le 2013-03-29 16:14, ? Brandon Ewing ? <nicotine at warningg.com> a ?crit :
>
> >Is there a knob in Cisco IOS to enable sending the MED learned from an
> >iBGP peer to an eBGP peer?
>
> No. You can't propagate a MED received via iBGP to an eBGP neighbor but
> you could set the MED from the IGP metric to the BGP next-hop as follow:
>
>
> router bgp x
> neighbor y.y.y.y remote y
> neighbor y.y.y.y route-map setMed
>
> route-map setMed permit 10
> set metric-type internal
>
> >Currently, it appears that if an iBGP route is learned from a local
> >network/aggregate statement, the MED is sent to an eBGP peer, but if
> >the iBGP route is learned from an iBGP peer, no MED is set on the
> >update to the eBGP peer.
>
> HR> This is normal behaviour. If the MED is learnt over iBGP it will not
> be sent to an eBGP neighbor.
>
> >
> >
> >Confirmed this in my 7206VXR lab, appears to be so in production on my
> >Sup720s, but my Foundry MLX series appear to send the learned MED
> >regardless.
> >
> >Lab output (Route sourced by netowrk statement on R21, advertised to R2
> >in same AS, who advertises it to R1 in different AS):
> >
> >R21#show ip bgp 192.168.40.0
> >BGP routing table entry for 192.168.40.0/24, version 2
> >Paths: (1 available, best #1, table Default-IP-Routing-Table)
> > Advertised to update-groups:
> > 1
> > Local
> > 0.0.0.0 from 0.0.0.0 (2.2.2.21)
> > Origin IGP, metric 10000, localpref 100, weight 32768, valid,
> >sourced, local, best
> >
> >R2#show ip bgp 192.168.40.0
> >BGP routing table entry for 192.168.40.0/24, version 2
> >Paths: (1 available, best #1, table Default-IP-Routing-Table)
> > Advertised to update-groups:
> > 2
> > Local
> > 2.2.2.21 (metric 65) from 2.2.2.21 (2.2.2.21)
> > Origin IGP, metric 10000, localpref 100, valid, internal, best
> >
> >
> >R1#show ip bgp 192.168.40.0
> >BGP routing table entry for 192.168.40.0/24, version 3
> >Paths: (1 available, best #1, table Default-IP-Routing-Table)
> > Not advertised to any peer
> > 65002
> > 1.1.2.2 from 1.1.2.2 (2.2.2.2)
> > Origin IGP, localpref 100, valid, external, best
> >
> >--
> >Brandon Ewing
> >(nicotine at warningg.com)
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 29 Mar 2013 18:21:40 -0700
> From: Bruce Pinsky <bep at whack.org>
> To: Andrey Petrenko <andy.petrenko at gmail.com>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Cisco ASA static dhcp binding
> Message-ID: <3378390347b6b07b76d649cea062d59d at whack.org>
> Content-Type: text/plain; charset="UTF-8"
>
>
>
>
> On Fri, 29 Mar 2013 19:16:11 +0300, Andrey Petrenko <
> andy.petrenko at gmail.com> wrote:
> > Hello everyone! I have Cisco ASA 5510 (8.4(5)). Can i configure dhcp
> > servers with static mapping? (e.g for mac xxxx:yyyy:zzzz assign ip
> > addr 192.168.1.100?
> >
>
> Unfortunately, no.
>
> --
> ==========
> bpe
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 30 Mar 2013 13:17:00 +0430
> From: s m <sam.gh1986 at gmail.com>
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] how NAt works from outside to inside
> Message-ID:
> <
> CAA_1SgGGNvk-dPbs+2osTnLSEDPUbxSZs3YTTfVfy0kN3+KcbA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> hello all
>
> i am newbie in NAT and i have some problem. i want to have a dynamic
> nat and this is my topology:
>
> 192.168.1.1-----> cisco 2800 ------> 192.168.2.1
>
> and this is my configuration in cisco 2800:
>
> interface GigabitEthernet 0/0
> ip address 192.168.2.2 255.255.255.0
> ip nat outside
> ip virtual-reassebly in
> duplex auto
> speed auto
>
> interface GigabitEthernet 0/1
> ip address 192.168.1.2 255.255.255.0
> ip nat inside
> ip virtual-reassebly in
> duplex auto
> speed auto
>
> ip nat pool t 192.168.2.50 192.168.2.60 netmask 255.255.255.0
> ip nat inside source list 1 pool t
> access-list 1 permit any
>
> when i ping 192.168.2.1 from 192.168.1.1 (from inside to outside),
> every thing is ok and nat is done correctly but when i ping
> 192.168.1.1 from 192.168.2.1 (from outside to inside), packets that
> received in 192.168.2.1 are as below:
>
> request packets: src:192.168.2.1----> dst: 192.168.1.1
> reply packets: src: 192.168.2.50----> dst:192.168.2.1
>
> and 192.168.2.1 system accept these packets as its reply!!! i think
> this behavior is wrong, isn't it? how it is happen? moreover, if i put
> a freebsd system instead of cisco, everything is the same except that
> 192.168.2.1 does not accept the reply packets as its reply (as i
> expected!!). please let me know if the cisco behavior is correct or
> not and if it is correct, how cisco router do that?
>
> please help me if i am misunderstanding.
> thanks in advance
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 30 Mar 2013 10:47:25 +0000
> From: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> To: Riccardo S <dim0sal at hotmail.com>, "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] community on bgp update
> Message-ID:
> <BB4FFD2794CF464FAA3A5C899EC94B5428AADB66 at xmb-rcd-x08.cisco.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> On 29/03/2013 16:46, "Riccardo S" <dim0sal at hotmail.com> wrote:
>
> >Hi
> >do I get the same result with route-map test-1 and test-2 in setting
> >these community on BGP update ?
> >
> >*******************************
> >route-map test-1 permit 10
> >match ip address prefix-list site-a
> >set community 1:1
> >set community 1:2 additive
> >
> >
> >*******************************
> >route-map test-2 permit 10
> >match ip address prefix-list site-a
> >set community 1:1
> >continue
> >!
> >route-map test-2 permit 20
> >match ip address prefix-list site-a
> >set community 1:2 additive
>
> the result might be different, as the test-1 config results in this:
>
> route-map test-1 permit 10
> match ip address prefix-list site-a
> set community 1:1 1:2 additive
> !
>
>
> and this one would add both communities to any communities already on the
> route, while prefixes processed by test-2 will have only 1:1 1:2, with all
> other communities removed.
>
>
> >
> >
> >And could you please give me an example of a route-map that match the
> >route marked before with 1:1 and 1:1 + 1:2 ?
> >
> >I was wondering if this is ok:
> >
> >ip policy-list PERMIT100 permit
> >match community 1
> >!
> >ip policy-list PERMIT200 permit
> >match community 2
> >!
> >ip community-list 1 permit 1:1
> >ip community-list 2 permit 1:2
> >!
> >!
> >!
> >route-map only1-1 permit 10 <---- does it match only if it's present
> >1:1 ?
> >match policy-list PERMIT100
>
> no, it will also match "1:1 1:2", you would need to use "match community 1
> exact-match" in the policy-list.
>
>
> >route-map 1-2 permit 10 <---- does it match only if are
> >presend 1:1 AND 1:2 ?
> >match policy-list PERMIT100
> >match policy-list PERMIT200
>
> no, you would need to do match on "ip community-list 12 permit 1:1 1:2",
> which creates an AND.
>
> hth
>
> oli
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 30 Mar 2013 11:52:59 +0000
> From: Phil Mayers <p.mayers at imperial.ac.uk>
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] netflow with source-mac address?
> Message-ID: <5156D21B.9020901 at imperial.ac.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/29/2013 06:41 PM, Nick Hilliard wrote:
> > On 29/03/2013 17:38, Gert Doering wrote:
> >> So that would also exclude Sup2T-based systems, using LAN cards
> (67/68/69xx)?
> >
> > Honestly, I don't know. The DFC4 on the lan cards may fix this. Maybe
> > someone from Cisco can clarify?
>
> This:
>
>
> http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps11821/ps11846/product_bulletin_c25-717747_ps708_Products_Bulletin.html
>
> ...talks about 15.1(SY) on the sup2T and says:
>
> """NetFlow (TNF) Export L2 MAC and Port Information for IPv4
> This feature gives you a way to find out the NetFlow information for
> destination and source MAC address along with the port LTL. This is
> useful when a bot on the network is spoofing the IP address. We will be
> able to track this down with the MAC address using NetFlow."""
>
> I had a feeling I'd seen mention of that feature.
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 30 Mar 2013 13:13:57 +0100
> From: Gert Doering <gert at greenie.muc.de>
> To: Phil Mayers <p.mayers at imperial.ac.uk>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] netflow with source-mac address?
> Message-ID: <20130330121357.GX17727 at greenie.muc.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> On Sat, Mar 30, 2013 at 11:52:59AM +0000, Phil Mayers wrote:
> >
> http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps11821/ps11846/product_bulletin_c25-717747_ps708_Products_Bulletin.html
> >
> > ...talks about 15.1(SY) on the sup2T and says:
> >
> > """NetFlow (TNF) Export L2 MAC and Port Information for IPv4
> > This feature gives you a way to find out the NetFlow information for
> > destination and source MAC address along with the port LTL. This is
> > useful when a bot on the network is spoofing the IP address. We will be
> > able to track this down with the MAC address using NetFlow."""
>
> This is extremely cool.
>
> I'm somewhat disappointed by the "for IPv4" bit, though.
>
> gert
>
> --
> USENET is *not* the non-clickable part of WWW!
> //
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> gert at greenie.muc.de
> fax: +49-89-35655025
> gert at net.informatik.tu-muenchen.de
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 305 bytes
> Desc: not available
> URL: <
> https://puck.nether.net/pipermail/cisco-nsp/attachments/20130330/6a82ef8f/attachment-0001.sig
> >
>
> ------------------------------
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
> End of cisco-nsp Digest, Vol 124, Issue 82
> ******************************************
>
> ______________________________________________________________________
> This email has been scanned by the brightsolid Email Security System.
> Powered by MessageLabs
> ______________________________________________________________________
>
> ______________________________________________________________________
> "brightsolid" is used in this email to collectively mean brightsolid
> online innovation limited and its subsidiary companies brightsolid online
> publishing limited and brightsolid online technology limited.
> findmypast.co.uk is a brand of brightsolid online publishing limited.
> brightsolid online innovation limited, Gateway House, Luna Place, Dundee
> Technology Park, Dundee DD2 1TP. Registered in Scotland No. SC274983.
> brightsolid online publishing limited, The Glebe, 6 Chapel Place,
> Rivington Street, London EC2A 3DQ. Registered in England No. 04369607.
> brightsolid online technology limited, Gateway House, Luna Place, Dundee
> Technology Park, Dundee DD2 1TP. Registered in Scotland No. SC161678.
>
> Email Disclaimer
>
> This message is confidential and may contain privileged information. You
> should not disclose its contents to any other person. If you are not the
> intended recipient, please notify the sender named above immediately. It is
> expressly declared that this e-mail does not constitute nor form part of a
> contract or unilateral obligation. Opinions, conclusions and other
> information in this message that do not relate to the official business of
> brightsolid shall be understood as neither given nor endorsed by it.
> ______________________________________________________________________
> This email has been scanned by the brightsolid Email Security System.
> Powered by MessageLabs
> ______________________________________________________________________
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list