On Jan 28, 2014, at 4:07 PM, Nick Olsen <n...@flhsi.com> wrote: > While I see what you're saying. It's still not "Spoofed". > > The device in question receives the request. And then generates a response > with the src address of the egress interface of the device dst to the IP and > port that requested it... In this case. The GRE tunnel. Unless I'm missing > something here about replying to a request only on the interface which it > ingressed the device. And the fact that it's UDP. not TCP. So it's > fire-and-forget. > > Thus, Nothing was ever spoofed. It just simply was returned from a different > interface of the same device. From our point of view. We saw the packet of > DNS-SRC>OurCustomer. And the other ISP, Which transported the reply. only saw > Customer-SRC>DNS-DST.
Nope, what happens is I send from my IP address (lets say 10.0.0.1). I send a packet to 192.168.0.1. It has 172.16.0.1 as it's DNS server. 192.168.0.1 has a rule that says send UDP/53 packets I process to 172.16.0.1. Since i'm "outside" it's "NAT", the rule ends up taking the source IP, which isn't part of it's "NAT" set, and ends up copying my "source" IP into the packet, then forwards it to the DNS server. 172.16.0.1 is responding to 10.0.0.1 DIRECTLY. It took me awhile in looking at this to figure out what was happening. Was interesting when you find out the 192.168.0.1 CPE was doing. You may not call it "spoofing" as it's doing what it was supposed to do/configured to do, but it shouldn't be sending the packet with *my* IP address. - Jared
