Rich, et al, Circling back on some older threads... I'm doing this because I've been growing my cgnat environments and needing to remind myself of somethings, etc... If an attack is targeted at 1 ip address, you would think that if would/could affect all the napt-44 (nat overloaded/pat'd) ip's that hide behind it... but isn't that *IF* that traffic actually got through the nat boundary and flowed to the intended target(s) ? Unsolicited outside---->inside traffic I believe results in a deny of traffic... and I'm seeing that the nat actually builds those flows as drop flows.... I generated some traffic at a nat destination and I see all my traffic is "Drop"... now I wonder if this is a fast path like in asic (pfe) hardware being dropped... if so, it would seem that the nat boundary is yet a really nice way to quickly drop unsolicited inbound traffic from perhaps bad sources. My source where I was generating traffic... Hollywood-ip (only works in the movies) 256.256.191.133 (bad guy) Nat destination where I sending traffic to... 256.256.130.4 (victim/target) Now of course the resources/network outside the nat is bogged down, but the inside nat domain seems to be unaffected in this case from what I can tell. And again, I'm wondering if that "Drop" flow is lightweight/fast processing for the ms-mpc-128g juniper gear ? {master} agould@960> show services sessions destination-prefix 256.256.130.4/32 | grep 256.256.191.133 | refresh 1 ---(refreshed at 2019-02-07 12:36:45 CST)--- ---(refreshed at 2019-02-07 12:36:46 CST)--- ---(refreshed at 2019-02-07 12:36:47 CST)--- ---(refreshed at 2019-02-07 12:36:48 CST)--- ---(refreshed at 2019-02-07 12:36:49 CST)--- ---(refreshed at 2019-02-07 12:36:50 CST)--- ---(refreshed at 2019-02-07 12:36:51 CST)--- ---(refreshed at 2019-02-07 12:36:52 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:53 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:54 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:55 CST)--- TCP 256.256.191.133:54519 -> 256.256.130.4:443 Drop O 1 ICMP 256.256.191.133 -> 256.256.130.4 Drop O 1 ---(refreshed at 2019-02-07 12:36:56 CST)--- ---(refreshed at 2019-02-07 12:36:57 CST)--- ---(refreshed at 2019-02-07 12:36:58 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:36:59 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:37:00 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 ---(refreshed at 2019-02-07 12:37:01 CST)--- UDP 256.256.191.133:12998 -> 256.256.130.4:80 Drop O 1 UDP 256.256.191.133:24444 -> 256.256.130.4:80 Drop O 1 - Aaron -----Original Message----- From: Compton, Rich A [mailto:Rich.Compton@charter.com] Sent: Thursday, April 6, 2017 3:49 PM To: Aaron Gould; 'Ahmed Munaf'; 'Nanog@Nanog' Subject: Re: CGNAT Hi Aaron, thanks for the info. I¹m curious what you or others do about DDoS attacks to CGNAT devices. It seems that a single attack could affect the thousands of customers that use those devices. Also, do you have issues detecting attacks vs. legitimate traffic when you have so much traffic destined to a small group of IPs? Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr, Englewood, CO 80112