Very odd UDP 40000 request. Please help me understand
-
Since that's not a well known port, it's impossible to say. Where's it coming from?
-
@jknott said in Very odd UDP 40000 request. Please help me understand:
Since that's not a well known port, it's impossible to say. Where's it coming from?
I wish I knew... I only see it once and then no more. Wonder if it could be during bootup of the switches. Originating network is an internal one, not very much on it so guess I could try to close down non-essentials and hope for it to show. But what would try to use an entire network ID as destination, don't get the point...
Would there be a better way thannetstat -tulpnto see it's source?Edit: I now found two hits on WAN from outside to that port as well... May of course just be coincidental, mostly concerned of the one originating from inside
-
@furom said in Very odd UDP 40000 request. Please help me understand:
I wish I knew... I only see it once and then no more.
If you see it again, check the source address.
-
@jknott said in Very odd UDP 40000 request. Please help me understand:
@furom said in Very odd UDP 40000 request. Please help me understand:
I wish I knew... I only see it once and then no more.
If you see it again, check the source address.
I found the log-entries (and learned a lot more than what is visible in the gui is actually saved);
Feb 19 20:58:26 fw filterlog[42290]: 47,,,1000004620,mvneta1.10,match,block,in,4,0x0,,64,11917,0,none,17,udp,130,192.168.10.1,192.168.10.0,35514,40000,110 Feb 19 21:38:06 fw filterlog[47000]: 50,,,1000004620,mvneta1.10,match,block,in,4,0x0,,64,14014,0,none,17,udp,130,192.168.10.1,192.168.10.0,32924,40000,110As you can see, it originates from 10.1 with destination same networks ID...
This is a little interesting... Can't really say I am fully grasping what is going on here (or to be more precise, the correct order and sequence), but happened at the same place roughly, which makes me feel it's more than a coincidence?
Feb 19 20:58:23 fw kernel: .... Feb 19 20:58:24 fw kernel: .done. Feb 19 20:58:24 fw php[338]: rc.bootup: Gateway, NONE AVAILABLE Feb 19 20:58:24 fw kernel: done. Feb 19 20:58:24 fw php[338]: rc.bootup: Unbound /var/unbound/root.key file is corrupt, removing and recreating. Feb 19 20:58:25 fw php[338]: rc.bootup: sync unbound done. Feb 19 20:58:25 fw kernel: done. Feb 19 20:58:26 fw kernel: done. Feb 19 20:58:56 fw php[338]: rc.bootup: Feb 19 21:38:03 fw kernel: . Feb 19 21:38:03 fw kernel: done. Feb 19 21:38:03 fw kernel: done. Feb 19 21:38:04 fw php[455]: rc.bootup: Gateway, NONE AVAILABLE Feb 19 21:38:04 fw php[455]: rc.bootup: Default gateway setting Interface WAN_DHCP Gateway as default. Feb 19 21:38:04 fw kernel: done. Feb 19 21:38:05 fw php[455]: rc.bootup: sync unbound done. Feb 19 21:38:05 fw kernel: done. Feb 19 21:38:05 fw kernel: done. Feb 19 21:38:39 fw kernel: done. -
@furom said in Very odd UDP 40000 request. Please help me understand:
As you can see, it originates from 10.1 with destination same networks ID
A packet can't come from 10.1 over the Internet. That's part of the RFC1918 blocks and shouldn't be passed by the routers. Do you have a 10.1 network?
-
@jknott said in Very odd UDP 40000 request. Please help me understand:
Do you have a 10.1 network?
Well aware a private network address isn't routable. That's why I tried to be clear it was an internal network... I could have said private network perhaps. Yes, I do have this network, but still does not understand what is going on... I have several others and this is the only one with this "issue"
-
Well, since it's internal, then you check the MAC address to see what device it's coming from.
-
@jknott Hm. I already know what device have this network assigned as I set this up, but still no clue closer to what and why sent this peculiar packet? I'm sorry if this is a strange question, but I'm trying to learn :)
-
Unfortunately, my crystal ball is busted again, so I can't offer much more.
-
@jknott said in Very odd UDP 40000 request. Please help me understand:
Unfortunately, my crystal ball is busted again, so I can't offer much more.
Bummer... But thanks much for trying. There oughta be some way of finding out device on that vlan has tried to make the connection, I'll just continue trying, there must be a way. Have a good one :)
