[c-nsp] how NAt works from outside to inside
Matt Thompson
mthompson at brightsolid.com
Sun Mar 31 08:59:35 EDT 2013
Hi Sam,
apologies, I shouldn't try to be helpful so late on a Saturday night! I have indeed misread what you have asked.
Looking at the output:
request packets: src:192.168.2.1----> dst: 192.168.1.1
reply packets: src: 192.168.2.50----> dst:192.168.2.1
this looks correct to me. You are pinging 192.168.1.1 from 192.168.2.1. Your routing is sending the packet to the 192.168.2.2 address (outside interface of the router), which correctly routes it to the inside interface. There is no NAT being carried out at that stage.
The return packet however, comes from the source of 192.168.1.1 and is then NAT'd to 192.168.2.50 (the first available IP in the pool) as it egresses the outside interface heading back to 192.168.2.1.
Where are you swapping in the FreeBSD system? Is this instead of the 2800 or are you using Cisco devices as hosts on the .1 addresses? Does Ping work differently on this host, or is there a firewall of some kind at play? ICMP isn't like TCP so reply packets don't need an established connection.
Matt
From: s m [mailto:sam.gh1986 at gmail.com]
Sent: 31 March 2013 06:53
To: Matt Thompson
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] how NAt works from outside to inside
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<mailto: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> [mailto: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<mailto:cisco-nsp-request at puck.nether.net>
Sent: 30 March 2013 16:21
To: cisco-nsp at puck.nether.net<mailto: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<mailto: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<mailto:cisco-nsp-request at puck.nether.net>
You can reach the person managing the list at
cisco-nsp-owner at puck.nether.net<mailto: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<mailto:hritter at cisco.com>>
To: Brandon Ewing <nicotine at warningg.com<mailto:nicotine at warningg.com>>, "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>"
<cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
Subject: Re: [c-nsp] Cisco and BGP MED
Message-ID:
<16365C0CD422BB4685B2080FAE12EF330C9ED13E at xmb-aln-x12.cisco.com<mailto: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<mailto: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<http://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<http://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<http://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<mailto:nicotine at warningg.com>)
------------------------------
Message: 2
Date: Fri, 29 Mar 2013 18:21:40 -0700
From: Bruce Pinsky <bep at whack.org<mailto:bep at whack.org>>
To: Andrey Petrenko <andy.petrenko at gmail.com<mailto:andy.petrenko at gmail.com>>
Cc: cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] Cisco ASA static dhcp binding
Message-ID: <3378390347b6b07b76d649cea062d59d at whack.org<mailto: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<mailto: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<mailto:sam.gh1986 at gmail.com>>
To: cisco-nsp at puck.nether.net<mailto: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<mailto:CAA_1SgGGNvk-dPbs%2B2osTnLSEDPUbxSZs3YTTfVfy0kN3%2BKcbA 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<mailto:oboehmer at cisco.com>>
To: Riccardo S <dim0sal at hotmail.com<mailto:dim0sal at hotmail.com>>, "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>"
<cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
Subject: Re: [c-nsp] community on bgp update
Message-ID:
<BB4FFD2794CF464FAA3A5C899EC94B5428AADB66 at xmb-rcd-x08.cisco.com<mailto: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<mailto: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<mailto:p.mayers at imperial.ac.uk>>
To: cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] netflow with source-mac address?
Message-ID: <5156D21B.9020901 at imperial.ac.uk<mailto: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<mailto:gert at greenie.muc.de>>
To: Phil Mayers <p.mayers at imperial.ac.uk<mailto:p.mayers at imperial.ac.uk>>
Cc: cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] netflow with source-mac address?
Message-ID: <20130330121357.GX17727 at greenie.muc.de<mailto: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/<http://www.muc.de/~gert/>
Gert Doering - Munich, Germany gert at greenie.muc.de<mailto:gert at greenie.muc.de>
fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de<mailto: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<mailto: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<http://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<mailto:cisco-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
______________________________________________________________________
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
______________________________________________________________________
More information about the cisco-nsp
mailing list