Question for the IT pros
-
This IP that is connecting is owned by your isp?
-
Seems to be as its the same except for the last digit.
-
same as what as the last digit? Same as your gateway.. Did you contact your ISP..
-
same as what as the last digit? Same as your gateway.. Did you contact your ISP..
The last octet of my IP is one digit higher than the one that everything else is showing up as.
They just fixed it. The IP that was showing up was another customer IP. Seems someone made a typo when configuring their hardware this weekend and all the IP's were being translated as that customer being the source IP.
-
"Seems someone made a typo when configuring their hardware this weekend and all the IP's were being translated as that customer being the source IP. "
Doesn't work that way - but ok ;)
-
Well thats what the tech flunky told me when I was on the phone with them.
Meh no worries its fixed and working like it should now, I was just trying to understand how it could happen.
-
True that its working now is the main thing.. But some other customer putting the wrong IP on their device would not route all traffic to them and then send it on to you looking like it came from them or the gateway..
So lets say they put in your IP.. And the ISP said hey this traffic is for .14 (other guy).. Why would this other guy then send that traffic on to you, but source nat it as the ISP (your gateway IP) etc..
Without some more details and understanding of the actual traffic you were seeing, etc. Its not really possible to say exactly what happened.. But I am pretty freaking sure it was more than just simple typo by another end user customer ;)
-
No one of their tech's misconfigured the ISP's equiment. It was translating all traffic coming through it as a customers public IP so that everything hitting my wan, and likely others, looked like it was coming from the same IP address.
-
So they enabled source nat, while that would cause your issue - its bit more than a simple typo ;)
Good thing is they sorted it.. So they giving you any sort of credit for their mistake? I would push for some sort of rebate on your bill or credit towards next cycle ;) What can they say NO ;)
-
Nah, it's a small town outfit and they treat me pretty good. They already give me more bandwidth than I am supposed to get with my package (because I begged them for more) so I'm not going to bust their chops for a little mix up for a day and a half.
Thanks for the input.
-
True that its working now is the main thing.. But some other customer putting the wrong IP on their device would not route all traffic to them and then send it on to you looking like it came from them or the gateway..
So lets say they put in your IP.. And the ISP said hey this traffic is for .14 (other guy).. Why would this other guy then send that traffic on to you, but source nat it as the ISP (your gateway IP) etc..
Without some more details and understanding of the actual traffic you were seeing, etc. Its not really possible to say exactly what happened.. But I am pretty freaking sure it was more than just simple typo by another end user customer ;)
I recently learned that many network stacks will forward a packet not destined for it. This became very apparent when my ISPs router ran out of MAC address cache and started broadcasting traffic. I noticed I was getting the same packet multiple times from several different MAC addresses from iphones to ipods to Windows desktops to Android devices.
Lets assume we have a packet destined for 1.2.3.4, but the ISP broadcasts it. Then lets assume someone has a device in a DMZ behind a NAT, but their public IP is 1.2.3.5.
The packet gets broadcasted to everyone, so 1.2.3.5 gets the packet, forwards it to the DMZ device. The DMZ device sees the packet is not for it and instead forwards it back to its gateway, which is the NAT. The NAT now re-writes the packet to have a source of 1.2.3.5 and forwards it to 1.2.3.4.
edit: Similar thing for a wrongly assigned IP. If an upstream router forwarded the packets for 1.2.3.4 to 1.2.3.5, then if 1.2.3.5 was using a NAT could have rewritten the source to 1.2.3.5 and forwarded on to 1.2.3.4
-
"so 1.2.3.5 gets the packet, forwards it to the DMZ device. The DMZ device sees the packet is not for it and instead forwards it back to its gateway,"
Why would this happen??? Yes I agree with you if the ISP is broadcasting it to FF:FF:FF:FF:FF:FF that 1.2.3.5 would see the packet - but when it sees that its not for its IP but 1.2.3.4 any sane device would just drop it.. It sure and the F should not forward it anywhere or source nat it to its IP..
What exact hardware were you seeing this on, and how was this device setup?
-
The IP was for 1.2.3.4, but I bet the MAC was for 1.2.3.5. Lets say the upstream router of 2.2.2.2 was configured to forward traffic bound for 1.2.3.0/24 to the "gateway" 1.2.3.5, then the upstream router would send traffic for 1.2.3.4 to the MAC of 1.2.3.5.
As for the "just drop it" depends on how the DMZ is implemented. Some DMZ implementations will forward ALL non-matched traffic to the DMZ target
- Upstream router has 1.2.3.5 as the gateway for 1.2.3.0/24
- 1.2.3.5's NAT/firewall sees an incoming packet with its own MAC, but a destination IP not of its own. Since the packet does not match any known existing states, it forwards the packet to its DMZ NAT target
- The DMZ host receives a packet with an unknown target IP of 1.2.3.4 and forwards the packet back to its gateway to forward on, which seems to be a very common thing to happen
- NAT/Firewall/Router receives a packet destined to 1.2.3.4 from an internal NAT'd device and re-writes the source to be 1.2.3.5
- 1.2.3.4 receives a bunch of traffic from 1.2.3.5 and goes WTF mate?!
-
"Some DMZ implementations will forward ALL non-matched traffic to the DMZ target"
What sort of garbage device would do that?? That would be just insane!! Your talking some BS soho 20$ router with a dmz host function.. And then why in the would would said host then source nat that and send it back out? That is just Batshit crazy talk ;)
