yes... which leads back to a full circle on another aspect of ISP/NSP/WISP 
systems... 

Centralized Syslog 
with / easy access to retrieve info.. 

Lots of desired functionality, Monitoring, DDOS, logging etc etc would lead 
back to a centralized logging system. 

:) 

Faisal Imtiaz 
Snappy Internet & Telecom 
7266 SW 48 Street 
Miami, FL 33155 
Tel: 305 663 5518 x 232 

Help-desk: (305)663-5518 Option 2 or Email: [email protected] 

> From: [email protected]
> To: [email protected]
> Sent: Wednesday, December 28, 2016 11:26:39 AM
> Subject: Re: [AFMUG] Mikrotik - Carrier Grade NAT methods

> Yeah, DHCP lease info is the thing to save.
> From: Adam Moffett
> Sent: Wednesday, December 28, 2016 9:21 AM
> To: [email protected]
> Subject: Re: [AFMUG] Mikrotik - Carrier Grade NAT methods
> I think Eric is saying if you're going to the effort of logging NAT 
> translations
> then you also should log DHCP assignments. Which is true.
> ------ Original Message ------
> From: "Dennis Burgess" < [email protected] >
> To: "[email protected]" < [email protected] >
> Sent: 12/28/2016 5:50:22 AM
> Subject: Re: [AFMUG] Mikrotik - Carrier Grade NAT methods

>> But this is not required.. Something of course, you can do.

>> Dennis Burgess

>> www.linktechs.net – 314-735-0270 x103 – [email protected]

>> From: Af [mailto: [email protected] ] On Behalf Of Eric Kuhnke
>> Sent: Tuesday, December 27, 2016 8:01 PM
>> To: [email protected]
>> Subject: Re: [AFMUG] Mikrotik - Carrier Grade NAT methods

>> Assuming you have a NAT and dhcp pools of IPs defined inside the NAT, unique
>> pool per POP, if you do not have log files from your dhcp daemon, you are
>> taking a terrible risk... Log files are small relative to the cost of disk
>> space. In setups I have built in the past with the ISC dhcpd we kept logs 
>> going
>> back 24 months for which CPE at which MAC address had which IP address 
>> (whether
>> internal or an ARIN IP) at any given point in time, including the
>> lease/assignment handshake.

>> On Tue, Dec 27, 2016 at 5:58 PM, Mathew Howard < [email protected] > 
>> wrote:
>>> The problem I see with that though, is the subpoenas we've gotten are 
>>> generally
>>> just an IP address, and a time period... if this is coming from something 
>>> like,
>>> say, a facebook post, is there typically going to be any log of that sort of
>>> thing?

>>> Assigning port blocks would work fine for things like bittorrent DMCA 
>>> takedown
>>> notices, where they give you port information, but I'm not sure how you 
>>> would
>>> use it to track down a specific customer when all they give you is the IP
>>> address...

>>> On Tue, Dec 27, 2016 at 6:51 PM, Josh Reynolds < [email protected] > 
>>> wrote:
>>>> If you assign a port block per customer (PBA NAT in Juniper), you
>>>> don't really need to log anything... do you?

>>>> On Tue, Dec 27, 2016 at 3:45 PM, Adam Moffett < [email protected] > 
>>>> wrote:
>>>> > A recent thread about a subpoena made me wonder. Historically this hasn't
>>>> > been an issue for me because I've had access to enough public IP's...but 
>>>> > it
>>>> > might become an issue soon.

>>>> > Has anybody set up CGN with appropriate logging on Mikrotik?
>>>> > I'm thinking you would have to log every set of src-ip, dst-ip, src-port,
>>>> > and dst-port for each connection that a customer opens. Does simply
>>>> > checking the "log" checkbox on the srcnat rule generate enough data or is
>>>> > there more to it?

>>>> > Has anybody tried the method on the wiki
>>>>> (
>>>>> http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#Carrier-Grade_NAT_.28CGNAT.29_or_NAT444
>>>> > )
>>>> > where you assign a range of port numbers to each private IP? The idea is
>>>> > you don't have to log everything at that point because you know that a
>>>> > connection from port x corresponds to private ip y. Then you just need to
>>>> > keep track of who has which private IP. It seems like this would have a
>>>> > side effect of limiting the number of simultaneous connections a single
>>>> > customer could open....maybe not a bad thing.

>>>> > Thanks,
>>>> > Adam

Reply via email to