cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6591
Views
0
Helpful
22
Replies

Finding source of traffic - behind router

davidjknapp
Level 1
Level 1

I have an esoft internet gateway appliance that is producing this message :

Feb 25 00:00:21 System martian source 192.168.1.255 from 192.168.1.135, on dev br0
Feb 25 00:00:21 System ll header: 00:01:4e:01:7a:b4:00(Destination - E-soft App):1e:f7:ae:b6:c0:08:00(Source Router at 10.x.x.x)

Our network scheme is 10.x.x.x, with no 192.168.*.* subnets on the local lan.  However, for some reason the router behind this gateway is still forwarding traffic from 192.168.1.* to the gateway.  My router has 3 interfaces, 10.x.x.x; 10.x.x.x, and 72.x.x.x.  Not sure how traffic is even getting to the router, let alone being forwarded.

From the switch I can identify the the devices by the mac's using "show mac address-table", but I cannot determine the source of the traffic from the other side of the router.

How do I track down the source of this traffic?

2 Accepted Solutions

Accepted Solutions

So, the only two connections from the 3845 are the Gateway and the MPLS Switch.

We know that the internal network has no 192.168.x.x

What about the MPLS network?

You mentioned the 3845 has no route to 192.168.x.x, but it has a default gateway pointing to the Gateway (because you said that a traceroute to 192.168.x.x goes from the 3845 to the gateway).

Are those messages in the Gateway recent and constant messages?

Because as you describe it, there's no sign of 192.168.x.x inside the Gateway.

Somebody could be spoofing IPs and that's why it shows on the Gateway, but it seems the router does not see that.

You can try the following:

Since the Gateway claims that the 192.168.x.x comes from the 3845, you can do an ACL on the 3845:

access-list test permit ip host 192.168.0.0 0.0.255.255 any

access-list permit ip any any

Apply the ACL to the interface of the 3845 connected to the Gateway, so we'll see if the ACL shows hitcounts when this happen again.

This will prove if the path to 192.168.x.x is indeed passing through the 3845.

Federico.

View solution in original post

David

Apologies but i gave some misleading info. To log port numbers your acl must match on port numbers so can you make your acl -

access-list 151 permit tcp 192.168.1.0 0.0.0.255 any range 1 65535 log

access-list 151 permit udp 192.168.1.0 0.0.0.255 any range 1 65535 log

access-list 151 permit icmp 192.168.1.0 0.0.0.255 any log
access-list 151 permit ip any any

then apply this acl to the interface that connect to your MPLS network.

Note that the router will buffer the logs so you may only see one entry for multiple hits.

Jon

View solution in original post

22 Replies 22

Hi,

Can you PING the 192.168.1.135 address from the router?

Is this a Cisco Router? Can you traceroute that IP?

Check the routing table on the router to see if there's a route for 192.168.x.x

Federico.

192.168.1.0/24 is not in the routing table, a tracert takes me out to our internet gateway then drops the packet.  Router is a 3845 with c3845-advsecurityk9-mz.124-3i.bin

Problem is that is the gateway that is seeing this message not the router. Is the message telling that the

packet comes from the 3845?

If so, the MAC address corresponds to the Ethernet interface of the 3845 connected to the Gateway?

According to the gateway (eSoft Appliance), The sending MAC address matches the g0/0 (LAN) MAC of the 3845.  The gateway is on the same subnet as that interface (router is x.x.x.1, gateway is x.x.x.5).  So the orgin of the packets could be comming form the lan or accross the MPLS which is also attached to that router.

So, the only two connections from the 3845 are the Gateway and the MPLS Switch.

We know that the internal network has no 192.168.x.x

What about the MPLS network?

You mentioned the 3845 has no route to 192.168.x.x, but it has a default gateway pointing to the Gateway (because you said that a traceroute to 192.168.x.x goes from the 3845 to the gateway).

Are those messages in the Gateway recent and constant messages?

Because as you describe it, there's no sign of 192.168.x.x inside the Gateway.

Somebody could be spoofing IPs and that's why it shows on the Gateway, but it seems the router does not see that.

You can try the following:

Since the Gateway claims that the 192.168.x.x comes from the 3845, you can do an ACL on the 3845:

access-list test permit ip host 192.168.0.0 0.0.255.255 any

access-list permit ip any any

Apply the ACL to the interface of the 3845 connected to the Gateway, so we'll see if the ACL shows hitcounts when this happen again.

This will prove if the path to 192.168.x.x is indeed passing through the 3845.

Federico.

OK... had to modify slightly..

interface GigabitEthernet0/0
description This is the local area connection
ip address 10.4.117.1 255.255.255.0
ip access-group 151 out
ip route-cache flow
duplex auto
speed auto
media-type rj45
negotiation auto
!
access-list 151 permit ip 192.168.1.0 0.0.0.255 any
access-list 151 permit ip any any
!

Here is the result after a few seconds of a "sho ip access-list" command


Extended IP access list 151
    10 permit ip 192.168.1.0 0.0.0.255 any (107 matches)
    20 permit ip any any (48573 matches)

This is very interesting...
You applied the ACL outbound to the interface directly connected to the Gateway correct?

The ACL shows that there are matches to traffic coming from 192.168.1.x

Now, we know that packets from 192.168.1.x are exiting out the interface of the 3845 to the Gateway, but through which interface is that traffic
coming?

Try implementing the same ACL on the inside interface or the interface connected to the MPLS switch to check which one is the traffic coming from.

Federico.

Good Call, the traffic is being generated from the S1/0, which is the MPLS hookup.  So, although we do not have a route to get back the the 192.168.1.x network, it is still routing out to the I-net gateway somehow.  I know I can put an access list on the serial interface blocking the traffic (below - I think).  How do I find out what ip the traffic is being routed from out on the MPLS network?  We have 18 sites.

access-list 101 permit 10.0.0.0 0.128.255.255 any

access-list 101 permit 172.16.0.0 0.240.255.255 any

Int S1/0

     ip access-group 101 in

As i understand the connection to the MPLS switch is through the 3845.

And the 3845 only has the internal network and a default gateway pointing to the esoft Gateway.

Is there also a connection between the esoft Gateway and the MPLS switch?

How do you communicate with your 18 sites through the MPLS cloud if the 3845 only has a default gateway to the esoft gateway and no other routes pointing anywhere else, and there are no other connections from your network to the MPLS cloud? Or this is not the case?

Federico.

The 3845 does have routes to the other networks, and the defaul gateway is to the esoft appliance. there is just no route to any 192.168.1.x networks.

The MPLS is terminated at the 3845 only, the eSoft Firewall is aattched to local lan and internet services provider only.

Below is routing table of 3845 for your pleasure....

     172.20.0.0/30 is subnetted, 2 subnets
S       172.20.243.16 [1/0] via 172.20.242.129
C       172.20.242.128 is directly connected, Serial1/0
S    192.168.26.0/24 [1/0] via 172.20.242.129
     10.0.0.0/8 is variably subnetted, 22 subnets, 2 masks
C       10.15.255.254/32 is directly connected, Loopback0
S       10.18.67.0/24 [1/0] via 172.20.242.129
S       10.4.124.0/24 [1/0] via 172.20.242.129
S       10.4.122.0/24 [1/0] via 172.20.242.129
S       10.4.123.0/24 [1/0] via 172.20.242.129
S       10.4.120.0/24 [1/0] via 172.20.242.129
S       10.4.121.0/24 [1/0] via 172.20.242.129
S       10.4.118.0/24 [1/0] via 172.20.242.129
S       10.4.119.0/24 [1/0] via 172.20.242.129
C       10.4.117.0/24 is directly connected, GigabitEthernet0/0
S       10.150.10.0/24 [1/0] via 172.20.242.129
S       10.150.11.0/24 [1/0] via 172.20.242.129
S       10.4.172.0/24 [1/0] via 172.20.242.129
S       10.4.173.0/24 [1/0] via 172.20.242.129
S       10.15.237.0/24 [1/0] via 172.20.242.129
S       10.15.235.0/24 [1/0] via 172.20.242.129
S       10.15.245.0/24 [1/0] via 172.20.242.129
S       10.15.247.0/24 [1/0] via 172.20.242.129
S       10.15.246.0/24 [1/0] via 172.20.242.129
S       10.15.248.0/24 [1/0] via 172.20.242.129
S       10.15.251.0/24 [1/0] via 172.20.242.129
S       10.15.250.0/24 [1/0] via 172.20.242.129
S    192.168.253.0/24 [1/0] via 172.20.242.129
S*   0.0.0.0/0 [1/0] via 10.4.117.5

Sounds like what is happening is the following:

192.168.1.x traffic is coming from the MPLS cloud.
Traffic reaches the 3845
Since the 3845 has no route to 192.168.1.x, it uses the default gateway 10.4.117.5 and that's why you see the log message in the esoft Gateway.

The question is:
Why is the MPLS cloud sending you traffic intended to 192.168.1.x?

Federico.

David

It would help if we knew what port/protocol was being used. Can you add the "log" keyword temporarily to your acl for just the line permitting 192.168.1.0 ie.

access-list 151 permit ip 192.168.1.0 0.0.0.255 any log
access-list 151 permit ip any any

Jon

I did so, but do not know where to look at the log  a "show log" does not dsiplay.  Sorry, newbie showing through.

David

No problem, have a look at this very short doc -

IOS logging

Basically -

1) enable logging if it is disabled ie. "logging on"

2) log to the buffer  "logging buffered"

"sh logging" should then show logs.

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco