Catch all IPs from certain port and add them to ipset list?

[privacyguy123]

Is this even possible? Finding nothing of use on Google ...

 

[ZebMcKayhan]

Is this even possible? Finding nothing of use on Google ...

The firewall could populate your ipset with ips based on matches on certain ports. Something like this would work I think:

ipset create MY_IPSET hash:net

iptables -t mangle -I PREROUTING -p tcp -i eth0 --sport 12345 -j SET --add-set MY_IPSET src --exist

Of course a lot of adjustment is needed depending on which source interface you are interested in to/from. Source port or destination port. If the source or destination ip should be added, tcp, udp or both...

 

[privacyguy123]

Of course a lot of adjustment is needed depending on which source interface you are interested in to/from. Source port or destination port. If the source or destination ip should be added, tcp, udp or both...

Seeing as it's a specialist port for a game we could just add every interface and both protocols in every direction to catch it all perhaps?

Or perhaps it makes more sense to just route all traffic via this port in iptables ...

 

[ZebMcKayhan]

Seeing as it's a specialist port for a game we could just add every interface and both protocols in every direction to catch it all perhaps?

Or perhaps it makes more sense to just route all traffic via this port in iptables ...

So destination port? Add destination ip to set? Any interface, something like:

iptables -t mangle -I PREROUTING -p tcp --dport 12345 -j SET --add-set MY_IPSET dst --exist
iptables -t mangle -I PREROUTING -p udp --dport 12345 -j SET --add-set MY_IPSET dst --exist

 

[privacyguy123]

Looks like that might catch everything, thanks!

 

[ZebMcKayhan]

Or perhaps it makes more sense to just route all traffic via this port in iptables ...

Depend on your purpose of course. You can't route ipsets directly anyway, you need to mark packets... if your purpose is routing of ports, then yes, just mark them directly

 

[privacyguy123]

Depend on your purpose of course. You can't route ipsets directly anyway, you need to mark packets... if your purpose is routing of ports, then yes, just mark them directly

Yep, it's being added to an ipset that's getting marked to go through WAN. Using DNS to catch the ips wasn't picking up everything and I noticed that the traffic it missed was all going through a specialist port 1119 for this specific game.

Strangely most of the hosts appear as NXDOMAIN via host or nslookup so it's impossible to catch them via DNS ipset it seems.

 

[ZebMcKayhan]

Yep, it's being added to an ipset that's getting marked to go through WAN. Using DNS to catch the ips wasn't picking up everything and I noticed that the traffic it missed was all going through a specialist port 1119 for this specific game.

Strangely most of the hosts appear as NXDOMAIN via host or nslookup so it's impossible to catch them via DNS ipset it seems.

If you already are using an ipset for this purpose, perhaps it's convenient to use the same ipset in this rule as in dnsmasq so both are adding ips to the same set. Might make a cleaner solution?

So, are the iptables command working? Is your ipset populated correctly by it?

 

[privacyguy123]

Yep I sent them to the same ipset list. Everything works as expected, yes thanks.

Annoyingly some games and services use amazonwebservices or similar CDNs and I'd prefer not to add them to an ipset list because it'll catch all sorts of websites so I guess I will just have to manually add stuff and eventually I will catch them all ... there's only so many servers 1 game can connect to right?

 

[ZebMcKayhan]

Yep I sent them to the same ipset list. Everything works as expected, yes thanks.

Annoyingly some games and services use amazonwebservices or similar CDNs and I'd prefer not to add them to an ipset list because it'll catch all sorts of websites so I guess I will just have to manually add stuff and eventually I will catch them all ... there's only so many servers 1 game can connect to right?

Well, if it makes it easier for you to mark the packet instead of adding the ip to an ipset it's just to

iptables -t mangle -I PREROUTING -p tcp --dport 12345 -j MARK --set-mark 0x8000/0x8000
iptables -t mangle -I PREROUTING -p udp --dport 12345 -j MARK --set-mark 0x8000/0x8000

For example...

I know there is a time-to-live option in ipsets so ips older than whatever you set gets erased. It may also help if the ip is changing within a larger organization.

You can also use ip and port combination ipsets to help minimize faulty entries: https://github.com/ZebMcKayhan/WireguardManager#create-and-setup-ipsets
But yeah, eventually it will probably come back to bite you, one way or the other...

 

[privacyguy123]

I know there is a time-to-live option in ipsets so ips older than whatever you set gets erased. It may also help if the ip is changing within a larger organization.

Interesting ... how do I set that or is it on by default?

 

[ZebMcKayhan]

Interesting ... how do I set that or is it on by default?

https://manpages.debian.org/testing/ipset/ipset.8.en.html

timeout​

All set types supports the optional timeout parameter when creating a set and adding entries. The value of the timeout parameter for the create command means the default timeout value (in seconds) for new entries. If a set is created with timeout support, then the same timeout option can be used to specify non-default timeout values when adding entries. Zero timeout value means the entry is added permanent to the set. The timeout value of already added elements can be changed by re-adding the element using the -exist option. The largest possible timeout value is 2147483 (in seconds). Example:

ipset create test hash:ip timeout 300
ipset add test 192.168.0.1 timeout 60
ipset -exist add test 192.168.0.1 timeout 600
When listing the set, the number of entries printed in the header might be larger than the listed number of entries for sets with the timeout extensions: the number of entries in the set is updated when elements added/deleted to the set and periodically when the garbage collector evicts the timed out entries.

 

[privacyguy123]

Can I add a timeout to all IPs being added to a ipset list via dnsmasq though? Where in the .conf would that go?

ipset=youtube.com/youtube

 

[ZebMcKayhan]

Can I add a timeout to all IPs being added to a ipset list via dnsmasq though? Where in the .conf would that go?

ipset=youtube.com/youtube

As long as the ipset is created with the timeout option it should be used for all added entries, even the ones dnsmasq adds... give it a go and test.

 

[privacyguy123]

As long as the ipset is created with the timeout option it should be used for all added entries, even the ones dnsmasq adds... give it a go and test.

Arbitrarly the largest possible is 24.855127314815 days? How strange lol

 

[privacyguy123]

It's not possible to add a timeout to an already created ipset?

 

[ZebMcKayhan]

Arbitrarly the largest possible is 24.855127314815 days? How strange lol

Yea, that's a little weird... thought it was 2^n but appearantly somewhere between 2^21 and 2^22... no idea why...

It's not possible to add a timeout to an already created ipset?

Don't think so... destroy it and create a new one... as long as dnsmasq is populating it, it wouldn't matter... or just create a new one and migrate bit by bit.

 

[privacyguy123]

Extreme rude awakening when I learned ipsets don't persist through reboot? I guess I need to add the "ipset -N xxx" to some sort of startup file?

 

[ZebMcKayhan]

Extreme rude awakening when I learned ipsets don't persist through reboot? I guess I need to add the "ipset -N xxx" to some sort of startup file?

Here is a script you can use for that:
https://github.com/ZebMcKayhan/WireguardManager#create-and-setup-ipsets