eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Server stats:

216
active users

#iptables

0 posts0 participants0 posts today
Replied in thread

Next, I had the theory that maybe the game was checking the source IP address of the packet to see it if matched the expected player's address based on the DirectPlay protocol phase.

So I added the following #iptables rule such that any traffic coming from the host towards Sarah's VM (192.168.1.242) would appear as if had come from James' VM (192.168.1.243).

iptables -t nat -A POSTROUTING -p udp -s <my ip> -d 192.168.1.242 -j SNAT --to-source 192.168.1.243

In the packet captures I could see that the source IP changed as intended and Sarah's game responded to these messages, but no trains were produced.

Continued thread

...
For some reason, #iptables logging doesn't appear in /var/log/syslog nor /var/log/kern.log nor journalctl.
What am I missing?

(Debian, rsyslog is installed, the log rule definitely is hit, the rule line looks like

-A FORWARD -j LOG --log-prefix "Dropped Packet: "

edit: does it matter that I'm running this in a Linux network namespace?

edit2: Uhh, yeah. git.kernel.org/pub/scm/linux/k
Apparently it's disabled by defait

git.kernel.orgMaking sure you're not a bot!

I did a mistake with my #dn42 network namespace #iptables setup! I made some crucial mistakes with the rules!

This should be better:

```
-A FORWARD -s fd00::/8 -d fd00::/8 -j ACCEPT
-A FORWARD -i eth0 -d fd00::/8 -j ACCEPT
-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
```

konec #IPTables je v dohlednu, částecně už i na dosah
za poslední rok jsem investoval čas a z předchozích #UFW a mrtvého #Shorewall přeskočil #FirewallD rovnou do nahatých #NFTables

- UFW využívá na pozadí iptables automaticky překládané do nftables, což je paskvil, který může vyhovovat závislákům na prehistorických iptables souborech "na které se nešahá", ale progresivnějšímu uživateli dost svazuje ruce
- navíc je nutné mít namemorovanou jejich speciální syntaxi a hlavně skladbu argumentů, takže většinou zadám validní příkaz na asi 4. pokus

- FirewallD si samozřejmě taky vymyslel vlastní příkazovou syntaxi, ale zároveň zapleveluje nftables nepoužívanými chainy, přijít k cizímu stroji a udělat nějakou drobnou úpravu v pravidlech je skoro na nobelovku

- NFtables jsou za mě nejpřehlednější a nejspolehlivější (největší kontrola), navíc umožňujou mít totální kontrolu nad firewallem a poslat k šípku snahy Dockeru o nadvládu
- navíc jsou velmi jednoduché a snadno pochopitelné

I've spent the last two days at $DayJob bashing my head against a problem. Finally got a solution engineered and deployed last night and it's working.

Woke up suddenly at about 4am this morning realizing that I massively over engineered it, and I could have solved the problem with about 3 #IPTables rules instead.

Why can't my brain think of these things before I deploy my overly elaborate contraptions?

#Linux #SysAdmins #NetworkAdmins

Ubuntu 24.04 system with a publicly-routable external IP address.

For a given incoming UDP port (<1024, call it port x, I can’t change this), I want to forward that to localhost (or the ens3 interface) on another port (>1024, port y) so I can invoke QEMU as non-root and forward port y to the emulated system’s port x via slirp.

Is this doable?

I’ve tried heaps of nat prerouted examples, but haven’t yet gotten anything to stick.

Boosts appreciated!

Since #Tumblr (owned by #MattMullenweg's #Automattic) renewed plans to join the #Fediverse, I suggest blocking them (as I have) for the same reason as #Threads: queerphobia and corporate tracking.

Just like the anti-Meta #FediPact (FediPact.online), there's now an anti-Automattic #FediPact2: FediPact2.online

Like I did with Meta, I wrote #iptables commands your #FediAdmin can use to drop all traffic to and from Automattic's IP addresses: pastebin.com/e5UKJCKU (source: AS2635)

I was finally forced to switch from #iptables to #nftables on a new #linux campus firewall setup.

I really should have made the switch years ago. Nftables is SO MUCH nicer! Having sets and variables has really simplified the configuration a ton.

I was happy with iptables for a really long time and so familiar with it, that I guess I was afraid of something new, but learning nftables has been fun and a lot easier than I expected for some reason.

Can anyone tell me what this #IPTables entry related to #DNS is?

#Asus has "helpfully" added this to my parents' router.

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
OUTPUT_DNS udp -- anywhere anywhere udp dpt:domain u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0"
OUTPUT_DNS tcp -- anywhere anywhere tcp dpt:domain u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0"

Continued thread

#iptables' #NETMAP target can alter the source IP range exclusive or the destination IP range.

Which it does is dependent on where you use the NETMAP target.

If you use the NETMAP target in the PREROUTING chain of the mangle table, it alters the destination ip range.

If you use the NETMAP target in the POSTROUTING chain of the mangle table, it alters the source IP range.

It has been zero days since #iptables solved a problem I shouldn't have to solve. Specifically the #NETMAP target.

iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -d 198.51.100.0/24 -i eth1 -j MARK --set-xmark 0xdeadbeef/0xffffffff

iptables -t nat -A PREROUTING -s 192.0.2.0/24 -d 198.51.100.0/24 -i eth1 -m mark --mark 0xdeadbeef -j NETMAP --to 192.0.2.0/24

iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -d 192.0.2.0/24 -o eth1 -m mark --mark 0xdeadbeef -j NETMAP --to 198.51.100.0/24

Ah, obviously. #docker only gets along with #firewalld if the latter is using the iptables backend (not the higher performing nftables default).
The #iptables backend is depreciated and slated for removal.

And of course there's no error message if configured "incorrectly", just random breakage that one then gets to debug!

I hate computers. I wish I was good enough at something else.

I have some networking questions but am totally out of my depth on this as I don't even know the terms to look for.

I have an ISP provided fiber box that acts as a router and WIFI endpoint and a separate
#opnsense machine I'd like to continue using as my #router/#firewall/#DHCP server. It was previously configured for a cable modem so I'd plug the modem into the port I'd designated as WAN and everything would route properly.

I would like a similar setup: the ISP box handles the fiber (and maybe the WiFi if it can be done, but I do have a separate wifi AP) and the opnsense box handles everything else. I can disable DHCP on the ISP box no problem and enable it on my opnsense box and plug it into the WAN port, but then I'm totally unsure of what I'm even trying to do, routing/iptables/LAN wise in order to route traffic appropriately to the LAN portion of the network.

I suspect I absolutely cannot use the WIFI on the ISP box, which, again, is fine; it'd be nice but I imagine that would introduce a level of complexity no one is here for (clients would be connecting to what is currently designated as the WAN? I'd probably need some VLAN stuff
maybe if it's even doable?)

Anyone have any idea what the appropriate terms are to even search for?

#opnsense #routing #homeNetworking #homeNetwork #LAN #WAN #fiberInternet #internet #networking #firewall #firewalls #pfsense #iptables #wifi