My fix for pf.conf after a "block in all"
Hello, I just want to share my solution taken from "Building Linux and OpenBSD firewalls" (av. on the Internet Archive) to solve the no traffic prb caused the block "block in all" statement. I moved the following statements: # dns pass in quick on $all_ifs proto udp from any port domain to any pass out quick on $all_ifs proto udp from any to any port domain # icmp pass in quick inet proto icmp all icmp-type 0 max-pkt-rate 100/10 pass in quick inet proto icmp all icmp-type 3 max-pkt-rate 100/10 pass in quick inet proto icmp all icmp-type 11 max-pkt-rate 100/10 (underlining icmp-type 3) setting them just after "block in all" and before anything else and this solved to me. Hope this can help anyone. -- Daniele Bonini
Re: ChatGPT writes a pf.conf by spec, earns an "F" grade
On 6/7/2023 5:36 PM, Stuart Longland VK4MSL wrote: On 8/6/23 06:32, Sean Kamath wrote: On Jun 7, 2023, at 01:28, Peter N. M. Hansteen wrote: Recorded at https://nxdomain.no/~peter/chatgpt_writes_pf.conf.html for those who would be interested. So in the thread that made you try it (https://bsd.network/@dch/110501874752402311) they said: "@pitrh I’m still waiting for it to explain my pf .conf setup to me” Which is kinda the inverse of “make me a pf.conf file”. I am curious if “explain to me this pf.conf in plain english” would work. :-) Probably about as well. It's the "Chinese Room" AI concept all over again. No "understanding", just rules. I find where its helpful is if I understand well what I want and can evaluate the answer when I see it with confidence. e.g. the other day I was working with a rather obscure app I had used a lot 2 yrs ago - influxDB. I knew I wanted to do, but forgot the syntax and its particular way of doing things was a little foggy. It got it right the first time. Yes, I could have trolled through the API documentation, or did a traditional google search, but it was a lot faster and was exactly what I wanted. ---Mike
Re: ChatGPT writes a pf.conf by spec, earns an "F" grade
On 8/6/23 06:32, Sean Kamath wrote: On Jun 7, 2023, at 01:28, Peter N. M. Hansteen wrote: Recorded at https://nxdomain.no/~peter/chatgpt_writes_pf.conf.html for those who would be interested. So in the thread that made you try it (https://bsd.network/@dch/110501874752402311) they said: "@pitrh I’m still waiting for it to explain my pf .conf setup to me” Which is kinda the inverse of “make me a pf.conf file”. I am curious if “explain to me this pf.conf in plain english” would work. :-) Probably about as well. It's the "Chinese Room" AI concept all over again. No "understanding", just rules. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: ChatGPT writes a pf.conf by spec, earns an "F" grade
> On Jun 7, 2023, at 01:28, Peter N. M. Hansteen wrote: > > Recorded at https://nxdomain.no/~peter/chatgpt_writes_pf.conf.html for those > who would be interested. So in the thread that made you try it (https://bsd.network/@dch/110501874752402311) they said: "@pitrh I’m still waiting for it to explain my pf .conf setup to me” Which is kinda the inverse of “make me a pf.conf file”. I am curious if “explain to me this pf.conf in plain english” would work. :-) Sean
ChatGPT writes a pf.conf by spec, earns an "F" grade
Prompted by a followup on Mastodon, I was enticed to see what feeding a prose spec for a pf.conf to ChatGPT would produce. TL;DR: it failed miserably, but in a way that would have lead the gullible to try it out raw, leading them down a route that would lead to loads of misery and frustration. Recorded at https://nxdomain.no/~peter/chatgpt_writes_pf.conf.html for those who would be interested. All the best, Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Question about pf.conf queues
Hello, gene...@nativemethods.com (J Doe), 2023.01.14 (Sat) 23:24 (CET): > On 2023-01-14 11:37, Marcus MERIGHI wrote: > > > Hello, > > > > not an answer but a little input below... > > > > gene...@nativemethods.com (J Doe), 2023.01.14 (Sat) 00:09 (CET): > > > I have a question regarding queuing and priorities in pf.conf on > > > OpenBSD 7.2. > > > > > > I have a basic gateway configuration - a PC with two NIC's (em0, em1). One > > > interface is connected to the LAN and one interface is connected to the > > > Internet with a public IP and with a bandwidth of approximately 60 Mbps > > > down > > > and 10 Mbps up. I perform NAT on the gateway. > > > > > > In terms of queuing, I'd like to make use of the following: > > > > > > ** Queue using HFSC for all outbound traffic > > > > > > ** Flow manager for the queue for fair queue utilization > > > > > > ** For TCP traffic I would like to use two priorities - one for TCP data > > > packets and one for TCP ACKs (as mentioned in Peter Hansteen's "Book of pf > > > 3rd edition" in chapter 7) > > > > > > Current configuration pf.conf: > > > > > > ext_if = "em0" > > > int_if = "em1" > > > > > > set skip on lo0 > > > > > > queue rootq on $ext_if bandwidth 55M max 55M > > > queue dataq parent rootq bandwidth 55M max 55M flows 1024 \ > > > qlimit 1024 default > > > > > > match out on $ext_if inet from ($int_if:network) to any nat-to ($ext_if:0) > > > > > > block all > > > > > > match in on $int_if inet tag LAN > > > match out on $ext_if inet queue dataq set prio (5, 6) tag INTERNET > > > > > > pass in quick on $int_if tagged LAN pass in quick on $int_if tagged LAN queue dataq ^^^ This way the packets get assigned to the queue when entering the machine's network handling code. And are treated accordingly when leaving on the outbound interface. (Avoid "quick", unless you want headaches as the ruleset grows.) > > > pass out quick on $ext_if tagged INTERNET > > > > In this message > > > > https://marc.info/?l=openbsd-misc=164521874319122 > > > > sthen@ said > > > > The queue is attached to a firewall state and all packets > > matching that state will pick it up. So if you have a named > > queue present on em0 but not em1, and match with "pass out on > > em1 set queue foo", packets transmitted on em1 will not be > > queued, but packets matching that state (return packets via em0) > > _will_ be queued. > > > > Marcus > > Hi Marcus, > > Thank you for your reply and thank you for the link to MARC. > > Based on what the referenced message states, am I not okay ? I have a > single queue and it is bound to a single NIC $ext_if. The pass rule that > allows the traffic to leave $ext_if should create the state for queuing of > outbound packets, should it not ? > > Or, are you saying that the queue assignment belongs on the pass rule and > not the match statement ? The queue assignment should happen as soon as the pf rules create the state, i.e. on the inbound interface, see the example above. Marcus > So instead of: > > match out on $ext_if inet queue dataq set prio (5, 6) tag INTERNET > . . . > pass out quick on $ext_if tagged INTERNET > > ... I could use: > > match out on $ext_if inet tag INTERNET > . . . > pass out quick on $ext_if set queue dataq set prio (5, 6) \ > tagged INTERNET > - J
Re: Question about pf.conf queues
> > It occurs to me that in my originally proposed configuration, I am not > > limiting the traffic with the two priorities to TCP traffic. This is > > necessary as this optimization applies only to TCP traffic and I should note > > that in Peter Hansteen's book he also does this. > > Good that you noticed that, but it's unnecessary. pf is smart enough to know > what traffic to apply it to. It's good to compare the output of pfctl(8) to > know > exactly what's changing and how things are getting parsed (`pfctl -s rules`, > `pfctl -nvf /etc/pf.conf`). I should clarify: without changing it to `proto tcp` like you did, it may indeed make a (small) difference because it could match UDP packets with a TOS of lowdelay as well. For me this is fine, as I'm comfortable with those UDP packets getting prioritized in addition to the TCP packets that match the rule. I didn't like the way I wrote it because it almost implies that they do the same thing and there's a difference. -- https://www.anthes.is/
Re: Question about pf.conf queues
Forgive me for the long mail. I went out of my way to be thorough because I see mails like this on misc@ fairly often. I had the same kinds of questions when I set up my OpenBSD router years ago so I can empathize. > My question are: > > 1. For better utilization of TCP traffic I have two priorities assigned to > the queue. Do I require more than one sub queue for this to work ? I > don't intend to subdivide my traffic up (i.e. a SSH queue, and HTTP/S > queue, etc.), I just want all my TCP traffic to benefit from better > utilization with the two priorities. No, and actually I'm pretty sure you can go without the sub queues entirely. Just one queue is enough and will work the way you want it to. > 2. If this configuration is currently correct, are they any other changes > I should make for better queuing (ie: better bandwidth utilization) ? I'll talk more about your queueing rule in a moment. > 3. Given the importance of time keeping, would it be a good idea to have > another queue for NTP traffic and use the highest priority of 7 for it ? I doubt it would harm anything, but it's probably unnecessary. In general, OpenBSD does the sensible thing. Sometimes improvements can be made through configuration, but it's usually best to clearly define and lay out the problem before deciding on a solution. When tweaking something, have a good understanding of what you're changing and why. Now I'll get more into your configuration. > queue rootq on $ext_if bandwidth 55M max 55M > queue dataq parent rootq bandwidth 55M max 55M flows 1024 \ > qlimit 1024 default As I understand it, that queue statement should be based on upload speed, not download speed. You can shape the traffic others send to you by controlling what you send to them. The nature of TCP congestion control (TCP slow start and friends) is why this approach works. It's like a telephone conversation---if the other person is talking (sending data) and you're silent for a long time (no acknowledgements/ACKs), the other person will ask if you're still there and wait for a response. So upload speed is the relevant metric because it's your response that you have control over. I can't take credit for the telephone analogy, it's from Solene's blog post on the subject[1]. Though I view her configuration itself as a bit of a special case. I've experimented with configurations that complex, and these days I mostly stick to the simple one rule configuration mentioned in pf.conf(5) under QUEUEING. > match out on $ext_if inet proto tcp set queue dataq set prio (5, 6) \ > tag INTERNET I'm aware of the priorities trick you're using[2] and I'd guess that the effect on top of FQ-CoDel + HFSC isn't a lot. But without proper testing, I don't know. Anyway, assigning to a queue and tagging are unnecessary here. The default queue will apply if the packets aren't assigned elsewhere. If the tagging is to make the rule's function clearer to you, then I'd just comment it instead. Also, it's perhaps a bit paranoid but I'd change two things. I'd add 'prio 3' to guard against accidentally overriding nondefault priority values, and I'd change the priority values to '(3, 4)'. The first change is so that it only matches normal priority packets and leaves everything else alone. The second change is so that outbound traffic remains at the default priority and therefore still shares an equal priority with inbound traffic (except for the dataless ACKs and packets with a TOS of lowdelay). As for mixing priorities and bandwidth shaping, I've felt unsure about how exactly they interact for quite a while now. I decided to put that doubt of mine to rest once and for all today, and this is what I could find. It seems that it used to be the case that they couldn't be used together, back in the days of ALTQ[3]. But there's evidence to suggest that they can be used together now[4][5]. I tested it and confirmed as much. > It occurs to me that in my originally proposed configuration, I am not > limiting the traffic with the two priorities to TCP traffic. This is > necessary as this optimization applies only to TCP traffic and I should note > that in Peter Hansteen's book he also does this. Good that you noticed that, but it's unnecessary. pf is smart enough to know what traffic to apply it to. It's good to compare the output of pfctl(8) to know exactly what's changing and how things are getting parsed (`pfctl -s rules`, `pfctl -nvf /etc/pf.conf`). > Does anyone have any feedback or pointers on this updated configuration ? My main suggestion is to test the modifications you're making to get objective results. This is both to build confidence and to make sure that you aren't accidentally screwing up your connection somehow. Usually the reason you'd change things like this is to avoid bufferbloat[6]. I like to use Flent[7] to test bufferbloat, but you're welcome to use web tools as well[8]. Run
Re: Question about pf.conf queues
On 2023-01-13 18:09, J Doe wrote: Hello, I have a question regarding queuing and priorities in pf.conf on OpenBSD 7.2. I have a basic gateway configuration - a PC with two NIC's (em0, em1). One interface is connected to the LAN and one interface is connected to the Internet with a public IP and with a bandwidth of approximately 60 Mbps down and 10 Mbps up. I perform NAT on the gateway. In terms of queuing, I'd like to make use of the following: ** Queue using HFSC for all outbound traffic ** Flow manager for the queue for fair queue utilization ** For TCP traffic I would like to use two priorities - one for TCP data packets and one for TCP ACKs (as mentioned in Peter Hansteen's "Book of pf 3rd edition" in chapter 7) Current configuration pf.conf: ext_if = "em0" int_if = "em1" set skip on lo0 queue rootq on $ext_if bandwidth 55M max 55M queue dataq parent rootq bandwidth 55M max 55M flows 1024 \ qlimit 1024 default match out on $ext_if inet from ($int_if:network) to any nat-to ($ext_if:0) block all match in on $int_if inet tag LAN match out on $ext_if inet queue dataq set prio (5, 6) tag INTERNET pass in quick on $int_if tagged LAN pass out quick on $ext_if tagged INTERNET My question are: 1. For better utilization of TCP traffic I have two priorities assigned to the queue. Do I require more than one sub queue for this to work ? I don't intend to subdivide my traffic up (i.e. a SSH queue, and HTTP/S queue, etc.), I just want all my TCP traffic to benefit from better utilization with the two priorities. 2. If this configuration is currently correct, are they any other changes I should make for better queuing (ie: better bandwidth utilization) ? 3. Given the importance of time keeping, would it be a good idea to have another queue for NTP traffic and use the highest priority of 7 for it ? Thanks, - J Hi list, It occurs to me that in my originally proposed configuration, I am not limiting the traffic with the two priorities to TCP traffic. This is necessary as this optimization applies only to TCP traffic and I should note that in Peter Hansteen's book he also does this. So an updated configuration is as follows (modification made on third match statement): ext_if = "em0" int_if = "em1" set sip on lo0 queue rootq on $ext_if bandwidth 55M max 55M queue dataq parent rootq bandwidth 55M max 55M flows 1024 \ qlimit 1024 default match out on $ext_if inet from ($int_if:network) to any \ nat-to ($ext_if:0) block all match in on $int_if inet tag LAN match out on $ext_if inet proto tcp set queue dataq set prio (5, 6) \ tag INTERNET pass in quick on $int_if tagged LAN pass out quick on $ext_if tagged INTERNET Does anyone have any feedback or pointers on this updated configuration ? Thanks, - J
Re: Question about pf.conf queues
On 2023-01-14 11:37, Marcus MERIGHI wrote: Hello, not an answer but a little input below... gene...@nativemethods.com (J Doe), 2023.01.14 (Sat) 00:09 (CET): I have a question regarding queuing and priorities in pf.conf on OpenBSD 7.2. I have a basic gateway configuration - a PC with two NIC's (em0, em1). One interface is connected to the LAN and one interface is connected to the Internet with a public IP and with a bandwidth of approximately 60 Mbps down and 10 Mbps up. I perform NAT on the gateway. In terms of queuing, I'd like to make use of the following: ** Queue using HFSC for all outbound traffic ** Flow manager for the queue for fair queue utilization ** For TCP traffic I would like to use two priorities - one for TCP data packets and one for TCP ACKs (as mentioned in Peter Hansteen's "Book of pf 3rd edition" in chapter 7) Current configuration pf.conf: ext_if = "em0" int_if = "em1" set skip on lo0 queue rootq on $ext_if bandwidth 55M max 55M queue dataq parent rootq bandwidth 55M max 55M flows 1024 \ qlimit 1024 default match out on $ext_if inet from ($int_if:network) to any nat-to ($ext_if:0) block all match in on $int_if inet tag LAN match out on $ext_if inet queue dataq set prio (5, 6) tag INTERNET pass in quick on $int_if tagged LAN pass out quick on $ext_if tagged INTERNET In this message https://marc.info/?l=openbsd-misc=164521874319122 sthen@ said The queue is attached to a firewall state and all packets matching that state will pick it up. So if you have a named queue present on em0 but not em1, and match with "pass out on em1 set queue foo", packets transmitted on em1 will not be queued, but packets matching that state (return packets via em0) _will_ be queued. Marcus Hi Marcus, Thank you for your reply and thank you for the link to MARC. Based on what the referenced message states, am I not okay ? I have a single queue and it is bound to a single NIC $ext_if. The pass rule that allows the traffic to leave $ext_if should create the state for queuing of outbound packets, should it not ? Or, are you saying that the queue assignment belongs on the pass rule and not the match statement ? So instead of: match out on $ext_if inet queue dataq set prio (5, 6) tag INTERNET . . . pass out quick on $ext_if tagged INTERNET ... I could use: match out on $ext_if inet tag INTERNET . . . pass out quick on $ext_if set queue dataq set prio (5, 6) \ tagged INTERNET - J
Re: Question about pf.conf queues
Hello, not an answer but a little input below... gene...@nativemethods.com (J Doe), 2023.01.14 (Sat) 00:09 (CET): > I have a question regarding queuing and priorities in pf.conf on > OpenBSD 7.2. > > I have a basic gateway configuration - a PC with two NIC's (em0, em1). One > interface is connected to the LAN and one interface is connected to the > Internet with a public IP and with a bandwidth of approximately 60 Mbps down > and 10 Mbps up. I perform NAT on the gateway. > > In terms of queuing, I'd like to make use of the following: > > ** Queue using HFSC for all outbound traffic > > ** Flow manager for the queue for fair queue utilization > > ** For TCP traffic I would like to use two priorities - one for TCP data > packets and one for TCP ACKs (as mentioned in Peter Hansteen's "Book of pf > 3rd edition" in chapter 7) > > Current configuration pf.conf: > > ext_if = "em0" > int_if = "em1" > > set skip on lo0 > > queue rootq on $ext_if bandwidth 55M max 55M > queue dataq parent rootq bandwidth 55M max 55M flows 1024 \ > qlimit 1024 default > > match out on $ext_if inet from ($int_if:network) to any nat-to ($ext_if:0) > > block all > > match in on $int_if inet tag LAN > match out on $ext_if inet queue dataq set prio (5, 6) tag INTERNET > > pass in quick on $int_if tagged LAN > pass out quick on $ext_if tagged INTERNET In this message https://marc.info/?l=openbsd-misc=164521874319122 sthen@ said The queue is attached to a firewall state and all packets matching that state will pick it up. So if you have a named queue present on em0 but not em1, and match with "pass out on em1 set queue foo", packets transmitted on em1 will not be queued, but packets matching that state (return packets via em0) _will_ be queued. Marcus > My question are: > > 1. For better utilization of TCP traffic I have two priorities assigned to > the queue. Do I require more than one sub queue for this to work ? I don't > intend to subdivide my traffic up (i.e. a SSH queue, and HTTP/S queue, > etc.), I just want all my TCP traffic to benefit from better utilization > with the two priorities. > > 2. If this configuration is currently correct, are they any other changes I > should make for better queuing (ie: better bandwidth utilization) ? > > 3. Given the importance of time keeping, would it be a good idea to have > another queue for NTP traffic and use the highest priority of 7 for it ? > > Thanks, > > - J
Question about pf.conf queues
Hello, I have a question regarding queuing and priorities in pf.conf on OpenBSD 7.2. I have a basic gateway configuration - a PC with two NIC's (em0, em1). One interface is connected to the LAN and one interface is connected to the Internet with a public IP and with a bandwidth of approximately 60 Mbps down and 10 Mbps up. I perform NAT on the gateway. In terms of queuing, I'd like to make use of the following: ** Queue using HFSC for all outbound traffic ** Flow manager for the queue for fair queue utilization ** For TCP traffic I would like to use two priorities - one for TCP data packets and one for TCP ACKs (as mentioned in Peter Hansteen's "Book of pf 3rd edition" in chapter 7) Current configuration pf.conf: ext_if = "em0" int_if = "em1" set skip on lo0 queue rootq on $ext_if bandwidth 55M max 55M queue dataq parent rootq bandwidth 55M max 55M flows 1024 \ qlimit 1024 default match out on $ext_if inet from ($int_if:network) to any nat-to ($ext_if:0) block all match in on $int_if inet tag LAN match out on $ext_if inet queue dataq set prio (5, 6) tag INTERNET pass in quick on $int_if tagged LAN pass out quick on $ext_if tagged INTERNET My question are: 1. For better utilization of TCP traffic I have two priorities assigned to the queue. Do I require more than one sub queue for this to work ? I don't intend to subdivide my traffic up (i.e. a SSH queue, and HTTP/S queue, etc.), I just want all my TCP traffic to benefit from better utilization with the two priorities. 2. If this configuration is currently correct, are they any other changes I should make for better queuing (ie: better bandwidth utilization) ? 3. Given the importance of time keeping, would it be a good idea to have another queue for NTP traffic and use the highest priority of 7 for it ? Thanks, - J
Re: pf.conf / scrub resulting in invalid checksum
Hello,
On Mon, Oct 10, 2022 at 06:52:00AM +0200, Bjorn Ketelaars wrote:
>
> (reply also send to tech@)
>
> In 2011 henning@ removed fiddling with the ip checksum of normalised
> packets in sys/net/pf_norm.c (r1.131). Rationale was that the checksum
> is always recalculated in all output paths anyway. In 2016 procter@
> reintroduced checksum modification to preserve end-to-end checksums
> (r1.189 of sys/net/pf_norm.c). Although I'm not sure, it seems as if
> somewhere in that timeslot checksum recalculation of normalised packets
> was broken.
>
> Issue got caught as net/mcast-proxy strictly adheres to RFC2236, which
> states that "When receiving packets, the checksum MUST be verified
> before processing a packet". After scrubbing a packet the checksum
> becomes invalid thus failing verification by net/mcast-proxy.
>
> I found two workarounds:
> 1.) rip out checksum verification from net/mcast-proxy;
> 2.) don't scrub packets with, e.g., id-random and/or no-df set.
>
> However, proposed solution is to fix this in pf. Diff below fixes the
> issue at hand.
>
> Comments/OK?
diff reads good to me. change makes sense in my opinion.
OK sashan
>
>
> Index: sys/net/pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.1140
> diff -u -p -r1.1140 pf.c
> --- sys/net/pf.c 3 Sep 2022 19:22:19 - 1.1140
> +++ sys/net/pf.c 10 Oct 2022 03:22:06 -
> @@ -164,7 +164,7 @@ void pf_add_threshold(struct
> pf_thres
> int pf_check_threshold(struct pf_threshold *);
> int pf_check_tcp_cksum(struct mbuf *, int, int,
> sa_family_t);
> -static __inline void pf_cksum_fixup(u_int16_t *, u_int16_t, u_int16_t,
> +__inline void pf_cksum_fixup(u_int16_t *, u_int16_t,
> u_int16_t,
> u_int8_t);
> void pf_cksum_fixup_a(u_int16_t *, const struct pf_addr *,
> const struct pf_addr *, sa_family_t, u_int8_t);
> @@ -1937,7 +1937,7 @@ pf_addr_wrap_neq(struct pf_addr_wrap *aw
> * Note: this serves also as a reduction step for at most one add (as the
> * trailing mod 2^16 prevents further reductions by destroying carries).
> */
> -static __inline void
> +__inline void
> pf_cksum_fixup(u_int16_t *cksum, u_int16_t was, u_int16_t now,
> u_int8_t proto)
> {
> Index: sys/net/pf_norm.c
> ===
> RCS file: /cvs/src/sys/net/pf_norm.c,v
> retrieving revision 1.224
> diff -u -p -r1.224 pf_norm.c
> --- sys/net/pf_norm.c 22 Aug 2022 20:35:39 - 1.224
> +++ sys/net/pf_norm.c 10 Oct 2022 03:22:06 -
> @@ -1646,14 +1646,21 @@ pf_scrub(struct mbuf *m, u_int16_t flags
> #ifdef INET6
> struct ip6_hdr *h6 = mtod(m, struct ip6_hdr *);
> #endif /* INET6 */
> + u_int16_told;
>
> /* Clear IP_DF if no-df was requested */
> - if (flags & PFSTATE_NODF && af == AF_INET && h->ip_off & htons(IP_DF))
> + if (flags & PFSTATE_NODF && af == AF_INET && h->ip_off & htons(IP_DF)) {
> + old = h->ip_off;
> h->ip_off &= htons(~IP_DF);
> + pf_cksum_fixup(>ip_sum, old, h->ip_off, 0);
> + }
>
> /* Enforce a minimum ttl, may cause endless packet loops */
> - if (min_ttl && af == AF_INET && h->ip_ttl < min_ttl)
> + if (min_ttl && af == AF_INET && h->ip_ttl < min_ttl) {
> + old = h->ip_ttl;
> h->ip_ttl = min_ttl;
> + pf_cksum_fixup(>ip_sum, old, h->ip_off, 0);
> + }
> #ifdef INET6
> if (min_ttl && af == AF_INET6 && h6->ip6_hlim < min_ttl)
> h6->ip6_hlim = min_ttl;
> @@ -1661,8 +1668,11 @@ pf_scrub(struct mbuf *m, u_int16_t flags
>
> /* Enforce tos */
> if (flags & PFSTATE_SETTOS) {
> - if (af == AF_INET)
> + if (af == AF_INET) {
> + old = *(u_int16_t *)h;
> h->ip_tos = tos | (h->ip_tos & IPTOS_ECN_MASK);
> + pf_cksum_fixup(>ip_sum, old, *(u_int16_t *)h, 0);
> + }
> #ifdef INET6
> if (af == AF_INET6) {
> /* drugs are unable to explain such idiocy */
> @@ -1674,6 +1684,9 @@ pf_scrub(struct mbuf *m, u_int16_t flags
>
> /* random-id, but not for fragments */
> if (flags & PFSTATE_RANDOMID && af == AF_INET &&
> - !(h->ip_off & ~htons(IP_DF)))
> + !(h->ip_off & ~htons(IP_DF))) {
> + old = h->ip_id;
> h->ip_id = htons(ip_randomid());
> + pf_cksum_fixup(>ip_sum, old, h->ip_id, 0);
> + }
> }
> Index: sys/net/pfvar.h
> ===
> RCS file: /cvs/src/sys/net/pfvar.h,v
> retrieving revision 1.510
> diff -u -p -r1.510 pfvar.h
> --- sys/net/pfvar.h 3 Sep 2022 14:57:54 -
Re: pf.conf / scrub resulting in invalid checksum
On Sun 09/10/2022 17:10, Björn Ketelaars wrote:
> I'm using mcast-proxy from ports as multicast routing proxy for use with
> my ISP's iptv platform. After some setting up i noticed from
> mcast-proxy's logging that all incoming packets are dropped because of
> IP invalid checksums [0]. At first I believed this was the result of
> hardware checksum offloading. However, after some more digging I found
> that my pf.conf was to blame, specifically:
>
> match inet scrub (max-mss 1460, no-df, random-id)
>
> Removing `no-df` and `random-id` as argument causes mcast-proxy to
> accept all incoming IGMP packets resulting in a working solution.
>
> After grepping sys/net/pf* i think that pf_test() calls pf_scrub(),
> which changes the fragment offset field and/or the identification field
> thus changing the packet header. However, it seems that the checksum of
> a changed packet is not updated.
>
> Can anyone shed a light on the above?
>
>
> [0]
> https://github.com/Esdenera/mcast-proxy/blob/master/usr.sbin/mcast-proxy/mcast-proxy.c#L539-L549
(reply also send to tech@)
In 2011 henning@ removed fiddling with the ip checksum of normalised
packets in sys/net/pf_norm.c (r1.131). Rationale was that the checksum
is always recalculated in all output paths anyway. In 2016 procter@
reintroduced checksum modification to preserve end-to-end checksums
(r1.189 of sys/net/pf_norm.c). Although I'm not sure, it seems as if
somewhere in that timeslot checksum recalculation of normalised packets
was broken.
Issue got caught as net/mcast-proxy strictly adheres to RFC2236, which
states that "When receiving packets, the checksum MUST be verified
before processing a packet". After scrubbing a packet the checksum
becomes invalid thus failing verification by net/mcast-proxy.
I found two workarounds:
1.) rip out checksum verification from net/mcast-proxy;
2.) don't scrub packets with, e.g., id-random and/or no-df set.
However, proposed solution is to fix this in pf. Diff below fixes the
issue at hand.
Comments/OK?
Index: sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1140
diff -u -p -r1.1140 pf.c
--- sys/net/pf.c3 Sep 2022 19:22:19 - 1.1140
+++ sys/net/pf.c10 Oct 2022 03:22:06 -
@@ -164,7 +164,7 @@ void pf_add_threshold(struct
pf_thres
int pf_check_threshold(struct pf_threshold *);
int pf_check_tcp_cksum(struct mbuf *, int, int,
sa_family_t);
-static __inline voidpf_cksum_fixup(u_int16_t *, u_int16_t, u_int16_t,
+__inline void pf_cksum_fixup(u_int16_t *, u_int16_t, u_int16_t,
u_int8_t);
voidpf_cksum_fixup_a(u_int16_t *, const struct pf_addr *,
const struct pf_addr *, sa_family_t, u_int8_t);
@@ -1937,7 +1937,7 @@ pf_addr_wrap_neq(struct pf_addr_wrap *aw
* Note: this serves also as a reduction step for at most one add (as the
* trailing mod 2^16 prevents further reductions by destroying carries).
*/
-static __inline void
+__inline void
pf_cksum_fixup(u_int16_t *cksum, u_int16_t was, u_int16_t now,
u_int8_t proto)
{
Index: sys/net/pf_norm.c
===
RCS file: /cvs/src/sys/net/pf_norm.c,v
retrieving revision 1.224
diff -u -p -r1.224 pf_norm.c
--- sys/net/pf_norm.c 22 Aug 2022 20:35:39 - 1.224
+++ sys/net/pf_norm.c 10 Oct 2022 03:22:06 -
@@ -1646,14 +1646,21 @@ pf_scrub(struct mbuf *m, u_int16_t flags
#ifdef INET6
struct ip6_hdr *h6 = mtod(m, struct ip6_hdr *);
#endif /* INET6 */
+ u_int16_told;
/* Clear IP_DF if no-df was requested */
- if (flags & PFSTATE_NODF && af == AF_INET && h->ip_off & htons(IP_DF))
+ if (flags & PFSTATE_NODF && af == AF_INET && h->ip_off & htons(IP_DF)) {
+ old = h->ip_off;
h->ip_off &= htons(~IP_DF);
+ pf_cksum_fixup(>ip_sum, old, h->ip_off, 0);
+ }
/* Enforce a minimum ttl, may cause endless packet loops */
- if (min_ttl && af == AF_INET && h->ip_ttl < min_ttl)
+ if (min_ttl && af == AF_INET && h->ip_ttl < min_ttl) {
+ old = h->ip_ttl;
h->ip_ttl = min_ttl;
+ pf_cksum_fixup(>ip_sum, old, h->ip_off, 0);
+ }
#ifdef INET6
if (min_ttl && af == AF_INET6 && h6->ip6_hlim < min_ttl)
h6->ip6_hlim = min_ttl;
@@ -1661,8 +1668,11 @@ pf_scrub(struct mbuf *m, u_int16_t flags
/* Enforce tos */
if (flags & PFSTATE_SETTOS) {
- if (af == AF_INET)
+ if (af =
pf.conf / scrub resulting in invalid checksum
I'm using mcast-proxy from ports as multicast routing proxy for use with my ISP's iptv platform. After some setting up i noticed from mcast-proxy's logging that all incoming packets are dropped because of IP invalid checksums [0]. At first I believed this was the result of hardware checksum offloading. However, after some more digging I found that my pf.conf was to blame, specifically: match inet scrub (max-mss 1460, no-df, random-id) Removing `no-df` and `random-id` as argument causes mcast-proxy to accept all incoming IGMP packets resulting in a working solution. After grepping sys/net/pf* i think that pf_test() calls pf_scrub(), which changes the fragment offset field and/or the identification field thus changing the packet header. However, it seems that the checksum of a changed packet is not updated. Can anyone shed a light on the above? [0] https://github.com/Esdenera/mcast-proxy/blob/master/usr.sbin/mcast-proxy/mcast-proxy.c#L539-L549
Re: Question regarding queueing in pf.conf(5) and WireGuard
You should apply queue on interface attached to network you want to limit
banwidth from. For example if your home network attached to 1GB em1 and you
want to limit web for certain ip addresses, perhaps something like this will
work
...
table { ip addrs list }
queue lanq on em1 bandwidth 950M
queue landefq parent lanq bandwidth 950M qlimit 1024 default
queue slowweb parent lanq bandwidth 32K max 64K
match in on em1 proto tcp from to port { www https } set queue slowweb
match out on egress inet from !(egress:network) to any nat-to (egress:0)
...
Some examples on Solene`s page:
https://dataswamp.org/~solene/2021-02-07-limit.html
And also there is a Book of PF written by Peter N. M. Hansteen
On Mon, Jun 14, 2021 at 11:59:59AM -0600, Ashlen wrote:
> Hello. I have an APU4D4 running OpenBSD and acting as a router for my
> home network. It connects to the Internet via pppoe(4), which uses em(4)
> as the physical interface.
>
> The router has a /etc/hostname.wg0 file that connects it as a client to
> my VPN provider on boot. Then, /etc/pf.conf has a nat-to rule for
> WireGuard, for IP masquerading. Here's said rule:
>
> match out on wg inet from !(wg:network) to any nat-to (wg:0)
>
> In pf.conf(5), there's mention of this simple configuration
> for bandwidth control:
>
> queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \
>default
>
> I want to employ this rule. My question is, which interface is
> appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0,
> as I'm unsure how pf(4) would classify traffic otherwise. However, I'm
> not confident in that conclusion, so I decided to ask.
>
> If additional details are needed, I'm happy to provide them.
>
> --
> https://amissing.link
>
Question regarding queueing in pf.conf(5) and WireGuard
Hello. I have an APU4D4 running OpenBSD and acting as a router for my home network. It connects to the Internet via pppoe(4), which uses em(4) as the physical interface. The router has a /etc/hostname.wg0 file that connects it as a client to my VPN provider on boot. Then, /etc/pf.conf has a nat-to rule for WireGuard, for IP masquerading. Here's said rule: match out on wg inet from !(wg:network) to any nat-to (wg:0) In pf.conf(5), there's mention of this simple configuration for bandwidth control: queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ default I want to employ this rule. My question is, which interface is appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0, as I'm unsure how pf(4) would classify traffic otherwise. However, I'm not confident in that conclusion, so I decided to ask. If additional details are needed, I'm happy to provide them. -- https://amissing.link
Re: WireGuard, Windows mobile laptop and pf.conf?
On 2020-12-29, Thomas Bohl wrote: > Hi, > >> wgport 53 >> Unbound is configured to only listen on the loopback interface, so that >> shouldn't be interfering... > > But it does > https://www.mail-archive.com/misc@openbsd.org/msg175837.html > > Right. You'll also find that some networks redirect all UDP port 53 traffic to some specific nameserver (they are wrong to do so, but that doesn't stop them) so 53 often won't work as well as some other ports. On 2020-12-28, Steve Williams wrote: > My hostname.wg0: > > wgkey > wgport 53 > wgpeer wgpka 25 wgaip 192.168.126.2/32 > inet 192.168.126.1/24 > up > > I haven't put "wgendpoint" in the OpenBSD config file as I don't know > what the remote IP address is. I assumed that "the local interface" > would update after receiving a correctly authenticated packet from my > Windows 10 laptop... That is correct. > In my Windows WireGuard client: > > [Interface] > PrivateKey = > Address = 192.168.126.2/24 > > [Peer] > PublicKey = > AllowedIPs = 0.0.0.0/1 > Endpoint = :53 AllowedIPs is wrong. You have configured wg(4) to use IPs in 192.168.126.0/24 which is not covered by 0.0.0.0/1: $ ipcalc 0.0.0.1/1 address : 0.0.0.1 netmask : 128.0.0.0 (0x8000) network : 0.0.0.0 /1 broadcast : 127.255.255.255 host min : 0.0.0.1 host max : 127.255.255.254 hosts/net : 2147483646 > Since I don't want to filter any of the Wireguard traffic, at the top of > the pf.conf, I have: > set skip on wg0 You might not want to _filter_ it, but for some configurations you may find it necessary to set max-mss in pf.conf and you can't do that if it's skipped either. This won't stop it connecting but experience has shown it's easy to forget about "set skip" if you try to add PF rules later.
[OT] Re: WireGuard, Windows mobile laptop and pf.conf?
Hello! hamdi201...@gmail.com (Andreas X), 2020.12.29 (Tue) 13:53 (CET): > > > I happen to come across this blog today that may help > > > you clarify some of your questions: > > > > https://ozgur.kazancci.com/secure-fast-vpn-server-wireguard-setup-on-openbsd-and-configure-windows-10-clients-to-connect-through-it/ > > > > I hope it helps. I am planning to set up one myself in the near future. > > Please keep us posted how yours turn out. > > > > Hakan Duran > > > Hi Hakan, thank you for this! > It works nicely, and has helped me a lot! I recently got it to work, too, after some fiddling, with this client: https://download.wireguard.com/windows-client/wireguard-installer.exe But... this requires admin rights under windows. Not for the installation, which would be natural, but for connecting, too. There's talk about workarounds: https://www.reddit.com/r/WireGuard/comments/frizel/solution_managing_wireguard_on_windows_as_a/ Which are... ugly? So, my question is: do you have a non-admin way to connect or are you just taking the risk? Sorry for the non-OpenBSD talk here, we should take this elsewhere; better reply privately, thanks! Marcus
Re: WireGuard, Windows mobile laptop and pf.conf?
> > > > > I happen to come across this blog today that may help > > you clarify some of your questions: > > > > > https://ozgur.kazancci.com/secure-fast-vpn-server-wireguard-setup-on-openbsd-and-configure-windows-10-clients-to-connect-through-it/ > > I hope it helps. I am planning to set up one myself in the near future. > Please keep us posted how yours turn out. > > Hakan Duran > Hi Hakan, thank you for this! It works nicely, and has helped me a lot!
Re: WireGuard, Windows mobile laptop and pf.conf?
Hi, wgport 53 Unbound is configured to only listen on the loopback interface, so that shouldn't be interfering... But it does https://www.mail-archive.com/misc@openbsd.org/msg175837.html
Re: WireGuard, Windows mobile laptop and pf.conf?
Hi Steve, On 20/12/28 04:14PM, Steve Williams wrote: > ... > > I am not sure where my issue is... I am going to cut to the chase here since I am no wireguard or OpenBSD expert; however, I happen to come across this blog today that may help you clarify some of your questions: https://ozgur.kazancci.com/secure-fast-vpn-server-wireguard-setup-on-openbsd-and-configure-windows-10-clients-to-connect-through-it/ I hope it helps. I am planning to set up one myself in the near future. Please keep us posted how yours turn out. Hakan Duran
WireGuard, Windows mobile laptop and pf.conf?
Hi,
I am not sure where my issue is...
As I understand, WireGuard is strictly UDP.
I am working on a road warrior setup, where one end of the tunnel is my
OpenBSD server with a static public IP address and the other end will be
Windows 7/10 laptops with random public IP addresses.
My hostname.wg0:
wgkey
wgport 53
wgpeer wgpka 25 wgaip 192.168.126.2/32
inet 192.168.126.1/24
up
I haven't put "wgendpoint" in the OpenBSD config file as I don't know
what the remote IP address is. I assumed that "the local interface"
would update after receiving a correctly authenticated packet from my
Windows 10 laptop...but perhaps the issue?
from ifcon|fig(8):
||wgendpoint| <https://man.openbsd.org/ifconfig#wgendpoint>ip port
Set the IP address and port to send the encapsulated packets to. If the
peer changes address, the local interface will update the address after
receiving a correctly authenticated packet. The IP address can be either
IPv4 or IPv6, and the port is a regular 16-bit UDP port.
In my Windows WireGuard client:
[Interface]
PrivateKey =
Address = 192.168.126.2/24
[Peer]
PublicKey =
AllowedIPs = 0.0.0.0/1
Endpoint = :53
Since I don't want to filter any of the Wireguard traffic, at the top of
the pf.conf, I have:
set skip on wg0
Then I am allowing incoming traffic to port 53.
# Wireguard running on DNS port
pass in on egress inet proto udp from any to (egress) port { domain }
When I initiate a connection from my road warrior setup (Windows 7,
WireGuard client which has the IP / Port configured of my OpenBSD
server), it is just continually retrying.
2020-12-28 12:22:54.401: [TUN] [OpenBSD] peer(IQsw…D4W8) - Handshake did
not complete after 5 seconds, retrying (try 2)
On my OpenBSD box, I can tcpdump -i em0 (egress, public IP address) and
see the packets getting to the OpenBSD box from the Windows laptop..
However, when I doing a tcpdump -i wg0, there is no traffic at all.
Unbound is configured to only listen on the loopback interface, so that
shouldn't be interfering...
(/var/unbound/etc/unbound.conf)
server:a
interface: 127.0.0.1
interface: ::1
Hum... now that I am thinking about it...how does it all work?
1. A packet leaves wg0 interface with 192.168.126.1 ip address
2. The packet is routed to the default gateway (egress)
3. The packet hits the Internet and is dropped as a non-routable IP
address
or...
Does the packet get routed out my external interface, whereby the NAT
rule would apply?
match out on egress inet from !(egress:network) to any nat-to (egress:0)
I'm just a little bit lost on how to configure pf for this all.
Thanks,
Steve W.
Re: pf.conf parser/lint
On Mon, Dec 21, 2020 at 07:28:54PM -0800, Sean Kamath wrote: > > On Dec 21, 2020, at 14:24, Aham Brahmasmi wrote: > > For the defaults, I try to explicitly write some of them sometimes. I > > find this helpful because it is difficult for me to remember what the > > defaults are. However, I do understand that I run the risk of being > > caught unawares if the defaults are changed for some good reason. > > Trade-offs :) > > That is what I use comments for. ;-) > > a) Tells me what I *think* the defaults are > b) Reminds me I’m *using* the defaults > c) When the defaults change, makes it easy to find out why things break (if > they break, which they haven’t in recent memory) > > Sean Which raises the question of knowing when the defaults change. Waiting until things *obviously* break doesn't address the time that things *silently* break. Silent breakage seems like a pretty serious security problem. Having the syntax pass OK is not the same thing as having what you need or want. I really don't see how any linter can accomplish such a complex question. Is my conf REALLY doing the right thing? Seems to. But maybe not. For a good example, a small mistake in smtpd.conf will run just fine, but with truly disastrous results. Chris Bennett
Re: pf.conf parser/lint
> On Dec 21, 2020, at 14:24, Aham Brahmasmi wrote: > For the defaults, I try to explicitly write some of them sometimes. I > find this helpful because it is difficult for me to remember what the > defaults are. However, I do understand that I run the risk of being > caught unawares if the defaults are changed for some good reason. > Trade-offs :) That is what I use comments for. ;-) a) Tells me what I *think* the defaults are b) Reminds me I’m *using* the defaults c) When the defaults change, makes it easy to find out why things break (if they break, which they haven’t in recent memory) Sean
Re: pf.conf parser/lint
Namaste Peter, Tusen takk for your reply. > Sent: Saturday, December 19, 2020 at 3:32 PM > From: "Peter Nicolai Mathias Hansteen" > To: "misc" > Subject: Re: pf.conf parser/lint > > > > > 19. des. 2020 kl. 14:50 skrev Aham Brahmasmi : > >>> > >> > >> Always put your interfaces into groups. Identify based upon the groups. > > > > In case there are more such simple rules of thumb, could you please > > share them? > > I think that piece of advice is one of the more important ones you’re likely > to get. > > Adding to that, in my experience, the important thing is to make your > configurations as simple as possible but not simpler :) > > I would like to stress using pf.conf readability features as helpers to > keeping your config maintainable, so > > * use service names when feasible instead of port numbers, > * use tables for groups of IP addresses > * use macros where they do help readability > * write rules that specify only what would be deviation from the default (the > defaults are, in general sane) > * before actually loading a changed config, run pfctl -vnf /etc/pf.conf to se > what *actually* loads > > That last one will among other things show you the result of the ruleset > optimizer’s work, so when you see obviously generated table names, you likely > have a set of rules that differ only in their source or destination address. > That is a surprisingly frequent phenomenon, and for some reason more people > than you would think are unaware that you can initialize a table or even load > new content into one from a separate file. All of the above are good simple rules of thumb. For the defaults, I try to explicitly write some of them sometimes. I find this helpful because it is difficult for me to remember what the defaults are. However, I do understand that I run the risk of being caught unawares if the defaults are changed for some good reason. Trade-offs :) > If you haven’t already, you might glean a few useful bits from going through > the PF tutorial slides at https://home.nuug.no/~peter/pftutorial/ > <https://home.nuug.no/~peter/pftutorial/> and links therein. I have, and tusen takk once again for the slides, tutorials and talks. > All the best, > Peter Additionally, I encountered some more such useful rules of thumb from Stuart's reply[0] on another thread, which co-incidentally also mentions interface groups. " ...Tagging...received-on...interface groups...priority or queues or flow queues... " Dhanyavaad, ab [0] - https://marc.info/?l=openbsd-misc=160068271606631=2 -|-|-|-|-|-|-|--
Re: pf.conf parser/lint
> 19. des. 2020 kl. 14:50 skrev Aham Brahmasmi : >>> >> >> Always put your interfaces into groups. Identify based upon the groups. > > In case there are more such simple rules of thumb, could you please > share them? I think that piece of advice is one of the more important ones you’re likely to get. Adding to that, in my experience, the important thing is to make your configurations as simple as possible but not simpler :) I would like to stress using pf.conf readability features as helpers to keeping your config maintainable, so * use service names when feasible instead of port numbers, * use tables for groups of IP addresses * use macros where they do help readability * write rules that specify only what would be deviation from the default (the defaults are, in general sane) * before actually loading a changed config, run pfctl -vnf /etc/pf.conf to se what *actually* loads That last one will among other things show you the result of the ruleset optimizer’s work, so when you see obviously generated table names, you likely have a set of rules that differ only in their source or destination address. That is a surprisingly frequent phenomenon, and for some reason more people than you would think are unaware that you can initialize a table or even load new content into one from a separate file. If you haven’t already, you might glean a few useful bits from going through the PF tutorial slides at https://home.nuug.no/~peter/pftutorial/ <https://home.nuug.no/~peter/pftutorial/> and links therein. All the best, Peter — Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. signature.asc Description: Message signed with OpenPGP
Re: pf.conf parser/lint
Namaste Theo, I apologize for reincarnating this thread. > Sent: Friday, September 04, 2020 at 5:33 PM > From: "Theo de Raadt" > To: "Tommy Nevtelen" > Cc: misc@openbsd.org > Subject: Re: pf.conf parser/lint > > Tommy Nevtelen wrote: > > > On 04/09/2020 18.07, Brian Brombacher wrote: > > > Well, let’s say a Linter doesn’t exist and you can’t invest time to make > > > one. Do you have a lower environment, mirror-exact ideally, to run tests > > > on the pre-receive hook? > > > > > > It’s an interesting issue you’re trying to solve ;) > > > > > I didn't say I can't invest time. I just wondered if somebody else > > knew of a solution before would try to dabble with it.. I do have a > > lab env where stuff could be run but it would be very > > un-efficient.. also openbsds interface names are based on the drivers > > so I can't try stuff out in virtual machines since the interface names > > would differ. I guess I could do some macros for those and change them > > but this would be overkill for what I want to achieve. Also I do have > > a lot of different setups and setting up test machines all of them > > would cost a ton of money which is not worth it. And not what I was > > after. > > Always put your interfaces into groups. Identify based upon the groups. In case there are more such simple rules of thumb, could you please share them? It always helps little volks like me to learn and improve. I learnt about packet tagging/policy based filtering from the pf user's guide. I now use policy based filtering extensively. > > Yes it is terrible that we have driver names exposed! We should just > have eth1-20 etc, but if one of your hardware devices fails, all the > subsequent ones will renumber, so their names change, and you have > precisely the same problem of exposed driver names. > > We provide over FIVE ways to identify ports without using the hardware > driver names, but hey... this discussion is about the theory you can > check overall behaviour of a system by ignoring the important parts. > > Dhanyavaad, ab -|-|-|-|-|-|-|--
Re: pf.conf parser/lint
> We provide over FIVE ways to identify ports without using the hardware > driver names, but hey... this discussion is about the theory you can > check overall behaviour of a system by ignoring the important parts. I always put a description and group field in my hostname config so that it allow me to have pf use a more generic syntax and it's been doing wonder for me for years. But you said 5 ways? This is most likely a stupid question, but what other way is there? I don't mean to be sound like a jerk, I am truly curious as I don't know 5 ways for sure, and i sure would love to learn them. Thanks Daniel
Re: pf.conf parser/lint
Tommy Nevtelen wrote: > On 04/09/2020 18.07, Brian Brombacher wrote: > > Well, let’s say a Linter doesn’t exist and you can’t invest time to make > > one. Do you have a lower environment, mirror-exact ideally, to run tests > > on the pre-receive hook? > > > > It’s an interesting issue you’re trying to solve ;) > > > I didn't say I can't invest time. I just wondered if somebody else > knew of a solution before would try to dabble with it.. I do have a > lab env where stuff could be run but it would be very > un-efficient.. also openbsds interface names are based on the drivers > so I can't try stuff out in virtual machines since the interface names > would differ. I guess I could do some macros for those and change them > but this would be overkill for what I want to achieve. Also I do have > a lot of different setups and setting up test machines all of them > would cost a ton of money which is not worth it. And not what I was > after. Always put your interfaces into groups. Identify based upon the groups. Yes it is terrible that we have driver names exposed! We should just have eth1-20 etc, but if one of your hardware devices fails, all the subsequent ones will renumber, so their names change, and you have precisely the same problem of exposed driver names. We provide over FIVE ways to identify ports without using the hardware driver names, but hey... this discussion is about the theory you can check overall behaviour of a system by ignoring the important parts.
Re: pf.conf parser/lint
On 04/09/2020 18.07, Brian Brombacher wrote: Well, let’s say a Linter doesn’t exist and you can’t invest time to make one. Do you have a lower environment, mirror-exact ideally, to run tests on the pre-receive hook? It’s an interesting issue you’re trying to solve ;) I didn't say I can't invest time. I just wondered if somebody else knew of a solution before would try to dabble with it.. I do have a lab env where stuff could be run but it would be very un-efficient.. also openbsds interface names are based on the drivers so I can't try stuff out in virtual machines since the interface names would differ. I guess I could do some macros for those and change them but this would be overkill for what I want to achieve. Also I do have a lot of different setups and setting up test machines all of them would cost a ton of money which is not worth it. And not what I was after. We do have a simple script in place that checks for some keywords now which I would like to expand that's all. /T
Re: pf.conf parser/lint
> On Sep 4, 2020, at 12:03 PM, Tommy Nevtelen wrote: > > On 04/09/2020 17.40, Brian Brombacher wrote: On Sep 4, 2020, at 11:28 AM, Brian Brombacher wrote: >>> >>> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen wrote: Hi there misc! Is there an external pfctl linter? we have bunch pf firwalls for which we generate rules but also write some manual ones that get merged. Would be nice if we could lint the rules before committed to vcs.. (yes we test before they are applied on the machines as well but that is way too late in a sane pipeline imho) >> Sane pipeline... :) >> >> Developer machine: can that securely run pfctl -n? Linter is great... but >> there’s a ton more involved. > > Don't get too caught up on my wording :) > > What is the ton that would be involved? > > It would be to catch the most stupid typo/syntax issues not to check if the > full config is valid on a specific machine. > > My more exact use case would be a pre-recieve hook or a check before merging > to the production branch. > Well, let’s say a Linter doesn’t exist and you can’t invest time to make one. Do you have a lower environment, mirror-exact ideally, to run tests on the pre-receive hook? It’s an interesting issue you’re trying to solve ;) > > /T > >
Re: pf.conf parser/lint
Tommy Nevtelen wrote: > On 04/09/2020 17.24, Brian Brombacher wrote: > > > >> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen wrote: > >> > >> Hi there misc! > >> > >> Is there an external pfctl linter? we have bunch pf firwalls for which we > >> generate rules but also write some manual ones that get merged. Would be > >> nice if we could lint the rules before committed to vcs.. (yes we test > >> before they are applied on the machines as well but that is way too late > >> in a sane pipeline imho) > >> > >> Problem is that pfctl expects that all interfaces and everything is > >> correct (which makes sense for pfctl before loading). BUT it is hard to > >> run on a build machine or my laptop to get a general idea on where I'm at > >> (unless I'm missing some tricks somewhere) > >> > > Can the build machine securely request each server run pfctl -n -f > > temp_config ? > > > > That would verify it’ll load for sure on said server. > > This would not be practical for many reasons and is exactly what I > want to avoid doing hence the original question. As a test becomes more synthetic, predicting operation in reality becomes quite poor. I get a feeling that most pf configuration errors are related to unexpected flows in/out of interfaces, and you suggest a grammer checker which is ignorant of interface configuration. It won't go well.
Re: pf.conf parser/lint
On 04/09/2020 17.40, Brian Brombacher wrote: On Sep 4, 2020, at 11:28 AM, Brian Brombacher wrote: On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen wrote: Hi there misc! Is there an external pfctl linter? we have bunch pf firwalls for which we generate rules but also write some manual ones that get merged. Would be nice if we could lint the rules before committed to vcs.. (yes we test before they are applied on the machines as well but that is way too late in a sane pipeline imho) Sane pipeline... :) Developer machine: can that securely run pfctl -n? Linter is great... but there’s a ton more involved. Don't get too caught up on my wording :) What is the ton that would be involved? It would be to catch the most stupid typo/syntax issues not to check if the full config is valid on a specific machine. My more exact use case would be a pre-recieve hook or a check before merging to the production branch. /T
Re: pf.conf parser/lint
On 04/09/2020 17.24, Brian Brombacher wrote: On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen wrote: Hi there misc! Is there an external pfctl linter? we have bunch pf firwalls for which we generate rules but also write some manual ones that get merged. Would be nice if we could lint the rules before committed to vcs.. (yes we test before they are applied on the machines as well but that is way too late in a sane pipeline imho) Problem is that pfctl expects that all interfaces and everything is correct (which makes sense for pfctl before loading). BUT it is hard to run on a build machine or my laptop to get a general idea on where I'm at (unless I'm missing some tricks somewhere) Can the build machine securely request each server run pfctl -n -f temp_config ? That would verify it’ll load for sure on said server. This would not be practical for many reasons and is exactly what I want to avoid doing hence the original question. /T
Re: pf.conf parser/lint
> On Sep 4, 2020, at 11:28 AM, Brian Brombacher wrote: > > > >> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen wrote: >> >> Hi there misc! >> >> Is there an external pfctl linter? we have bunch pf firwalls for which we >> generate rules but also write some manual ones that get merged. Would be >> nice if we could lint the rules before committed to vcs.. (yes we test >> before they are applied on the machines as well but that is way too late in >> a sane pipeline imho) Sane pipeline... :) Developer machine: can that securely run pfctl -n? Linter is great... but there’s a ton more involved. >> >> Problem is that pfctl expects that all interfaces and everything is correct >> (which makes sense for pfctl before loading). BUT it is hard to run on a >> build machine or my laptop to get a general idea on where I'm at (unless I'm >> missing some tricks somewhere) >> > > Can the build machine securely request each server run pfctl -n -f > temp_config ? > > That would verify it’ll load for sure on said server. > >> So I've been looking into parse.y in pfctl. It's been a long time since I've >> messed around with very simple yacc stuff so kind of lost. >> >> Has anyone done anything like this? Would be good to know before I sink more >> time into this (and probably fail) :) >> >> /T >> >
Re: pf.conf parser/lint
> On Sep 4, 2020, at 10:51 AM, Tommy Nevtelen wrote: > > Hi there misc! > > Is there an external pfctl linter? we have bunch pf firwalls for which we > generate rules but also write some manual ones that get merged. Would be nice > if we could lint the rules before committed to vcs.. (yes we test before they > are applied on the machines as well but that is way too late in a sane > pipeline imho) > > Problem is that pfctl expects that all interfaces and everything is correct > (which makes sense for pfctl before loading). BUT it is hard to run on a > build machine or my laptop to get a general idea on where I'm at (unless I'm > missing some tricks somewhere) > Can the build machine securely request each server run pfctl -n -f temp_config ? That would verify it’ll load for sure on said server. > So I've been looking into parse.y in pfctl. It's been a long time since I've > messed around with very simple yacc stuff so kind of lost. > > Has anyone done anything like this? Would be good to know before I sink more > time into this (and probably fail) :) > > /T >
Re: pf.conf parser/lint
On Fri, Sep 4, 2020 at 10:51 AM Tommy Nevtelen wrote: > > Hi there misc! > > Is there an external pfctl linter? we have bunch pf firwalls for which > we generate rules but also write some manual ones that get merged. Would > be nice if we could lint the rules before committed to vcs.. (yes we > test before they are applied on the machines as well but that is way too > late in a sane pipeline imho) > > Problem is that pfctl expects that all interfaces and everything is > correct (which makes sense for pfctl before loading). BUT it is hard to > run on a build machine or my laptop to get a general idea on where I'm > at (unless I'm missing some tricks somewhere) > > So I've been looking into parse.y in pfctl. It's been a long time since > I've messed around with very simple yacc stuff so kind of lost. > > Has anyone done anything like this? Would be good to know before I sink > more time into this (and probably fail) :) > > /T > I wonder if you plug the BNF at the end of the man to something like https://github.com/josephwecker/autohighlight if you can have a 'linter' -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
pf.conf parser/lint
Hi there misc! Is there an external pfctl linter? we have bunch pf firwalls for which we generate rules but also write some manual ones that get merged. Would be nice if we could lint the rules before committed to vcs.. (yes we test before they are applied on the machines as well but that is way too late in a sane pipeline imho) Problem is that pfctl expects that all interfaces and everything is correct (which makes sense for pfctl before loading). BUT it is hard to run on a build machine or my laptop to get a general idea on where I'm at (unless I'm missing some tricks somewhere) So I've been looking into parse.y in pfctl. It's been a long time since I've messed around with very simple yacc stuff so kind of lost. Has anyone done anything like this? Would be good to know before I sink more time into this (and probably fail) :) /T
pf.conf set state-defaults pflow seemingly not exporting traffic
pf.conf set state-defaults pflow seemingly not exporting traffic
My money is on state-defaults working and I just am doing something
wrong, but I can't figure out what it is.
The sensor's information:
OpenBSD 6.7 (GENERIC.MP) #4: Wed Jul 15 11:16:20 MDT 2020
r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64
/compile/GENERIC.MP
bios0: PC Engines APU2
On the sensor in /etc/pf.conf each pass rule has modulate state. I
add (pflow) to each of these rules, flows export correctly. If I
don't explicitly add (pflow), I don't see netflow traffic.
Note about the collector:
Everything else in this message only involves the sensor. If I add
(pflow) to each "modulate state" pass rule /etc/pf.conf in the
sensor, the collector works fine. If I take it away, the collector
only generates files with no flow data, e.g. ls -l gives
root _netflow 100 Jul 20 23:50 ft-v05.2020-07-20.234501-0500
instead of lengths that reflected the explicit (pflow) rules on
the sensor the day before:
root _netflow 5546 Jul 19 04:35 ft-v05.2020-07-19.043001-0500
Please note that the size was 100 for every file for Jul 20, not
just for 23:50.
These dates are just one example. Going back and forth from
explicit (pflow) on the sensor generates the same sort of results.
End of note about the collector.
Both /etc/pf.conf and /etc/pf.conf.onlystatedefaultspflow contain
set state-defaults pflow pass log quick proto udp from flowgroup to
collector port $flowport modulate state \
label "flow $if $nr $srcaddr $dstaddr"
The only difference between the files is that
pf.conf.onlystatedefaultspflow lacks explicit (pflow).
i.e. if pf.conf has
pass log inet proto tcp to https modulate state (pflow)
then pf.conf.onlystatedefaultspflow has
pass log inet proto tcp to https modulate state
I've cleaned up the output of a typescript that shows the problem: If
I understand the output correctly, I have to explicitly add (pflow) to
the pass rules to get traffic on the pflow0 interface, and to see
traffic from my labeled rule that exports the flows.
First with only the set state-defaults:
step0# /sbin/pfctl -f /etc/pf.conf.onlystatedefaultspflow
step1# /usr/bin/netstat -b -I pflow0
NameMtu Network AddressIbytes Obytes
pflow01492 0 53359944
step2# /sbin/pfctl -s label | /usr/bin/grep flow
flow any 0 10.0.1.1 10.0.1.3 99 1 1300 0 0 1 1300 1
step3# /bin/echo "generating traffic on some other host"
step4# /usr/bin/netstat -b -I pflow0
NameMtu Network AddressIbytes Obytes
pflow01492 0 53359944
step5# /sbin/pfctl -s label | /usr/bin/grep flow
flow any 0 10.0.1.1 10.0.1.3 172 1 1300 0 0 1 1300 1
now loading ruleset with (pflow) on each rule with modulate state
step0# /sbin/pfctl -f /etc/pf.conf
step1# /usr/bin/netstat -b -I pflow0
NameMtu Network AddressIbytes Obytes
pflow01492 0 53360160
step2# /sbin/pfctl -s label|/usr/bin/grep flow
flow any 0 10.0.1.1 10.0.1.3 69 0 0 0 0 0 0 0
step3# /bin/echo "generating traffic on another host"
step4# /usr/bin/netstat -b -I pflow0
NameMtu Network AddressIbytes Obytes
pflow01492 0 53364552
step5# /sbin/pfctl -s label|/usr/bin/grep flow
flow any 0 10.0.1.1 10.0.1.3 95 3 4476 0 0 3 4476 1
Re: pf.conf set state-defaults pflow seemingly not exporting traffic
On Tue, 21 Jul 2020 19:35:17 +0200, Peter Nicolai Mathias Hansteen wrote: > pfctl -vnf pf.conf oh indeed it says pass out log on vlan10 proto tcp all flags S/SA modulate state (if-bound) but I understood why my pflow setup still works: it takes the flow from the internal interfaces :)
Re: pf.conf set state-defaults pflow seemingly not exporting traffic
> 21. jul. 2020 kl. 19:06 skrev Daniel Jakots :
>> Your ‘modulate state’ overrides the default. As you have seen, on
>> non-default rules you need to add any options explicitly.
>
> Are you sure?
> I have a working (AFAIK) pflow setup and I also have
> pass out log on $ext_if proto { tcp, udp } all modulate state
>
> (I checked the rule is used because if I comment it the outgoing
> traffic doesn't go anymore)
The only way to be sure is to look at the actually loaded rule set (systat
rules or pfctl -vnf pf.conf), the boxes I have within easy reach do not use
these features at the moment, I’m afraid.
All the best,
—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
signature.asc
Description: Message signed with OpenPGP
Re: pf.conf set state-defaults pflow seemingly not exporting traffic
On Tue, 21 Jul 2020 18:52:40 +0200, Peter Nicolai Mathias Hansteen
wrote:
> > 21. jul. 2020 kl. 17:42 skrev marfabastewart
> > :
> >
> > pf.conf set state-defaults pflow seemingly not exporting traffic
> >
> > My money is on state-defaults working and I just am doing something
> > wrong, but I can't figure out what it is.
> >
> > The sensor's information:
> > OpenBSD 6.7 (GENERIC.MP) #4: Wed Jul 15 11:16:20 MDT 2020
> > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64
> > /compile/GENERIC.MP
> > bios0: PC Engines APU2
> >
> > On the sensor in /etc/pf.conf each pass rule has modulate state. I
> > add (pflow) to each of these rules, flows export correctly. If I
> > don't explicitly add (pflow), I don't see netflow traffic.
>
> That is indeed the expected behavior.
>
> set state-defaults only sets the default so any rule without
> explicitly set state options will evaluate as having ‘keep state
> (pflow)’.
>
> Your ‘modulate state’ overrides the default. As you have seen, on
> non-default rules you need to add any options explicitly.
Are you sure?
I have a working (AFAIK) pflow setup and I also have
pass out log on $ext_if proto { tcp, udp } all modulate state
(I checked the rule is used because if I comment it the outgoing
traffic doesn't go anymore)
Cheers,
Daniel
Re: pf.conf set state-defaults pflow seemingly not exporting traffic
> 21. jul. 2020 kl. 17:42 skrev marfabastewart : > > pf.conf set state-defaults pflow seemingly not exporting traffic > > My money is on state-defaults working and I just am doing something > wrong, but I can't figure out what it is. > > The sensor's information: > OpenBSD 6.7 (GENERIC.MP) #4: Wed Jul 15 11:16:20 MDT 2020 > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64 > /compile/GENERIC.MP > bios0: PC Engines APU2 > > On the sensor in /etc/pf.conf each pass rule has modulate state. I > add (pflow) to each of these rules, flows export correctly. If I > don't explicitly add (pflow), I don't see netflow traffic. That is indeed the expected behavior. set state-defaults only sets the default so any rule without explicitly set state options will evaluate as having ‘keep state (pflow)’. Your ‘modulate state’ overrides the default. As you have seen, on non-default rules you need to add any options explicitly. All the best, — Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. signature.asc Description: Message signed with OpenPGP
Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
> > -- Forwarded message -- > From: Kevin Chadwick > To: misc@openbsd.org > Cc: > Bcc: > Date: Sun, 14 Jun 2020 13:58:39 + > Subject: Thoughts or links on optimally secure defaults for pf.conf and > fstab, whilst aiming to minimise support issues. > We are basing the server part of our products on OpenBSD. > > We care more about reducing support issues than say performance. > > We will have batteries but I hope to deploy some kind of root partition > redundancy, for upgrades. > > However, Is sync or softdep a better default for the best chance of avoiding > manual fsck/support issues? Hello, I just recently got to use OpenBSD (before FreeBSD, before that Linux) and what I found out about recently is FuguIta [1], it seems to be a OpenBSD Live System, where you can create an encrypted partition and save state data to it (etc, var, etc.), then read that back after boot into memory, with that you could have memory only solution going, which, as they say on their website, can work with as little as 64MB of ram (without X use). Now I imagen if you distribute your software on top of OpenBSD, you could manage to use FuguIta to create your own install system, as you control the hardware, you can configure the boot without user interaction (on their website they describe how to create your own system. So, If I needed more resilience against power outtages, I would give fuguIta a try, but of course it depends on your configuration and the software you are running / service you are providing. Best Rai [1] http://fuguita.org
Re: Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
On 2020-06-14, Kevin Chadwick wrote: > We are basing the server part of our products on OpenBSD. > > We care more about reducing support issues than say performance. > > We will have batteries but I hope to deploy some kind of root partition > redundancy, for upgrades. You'll need to cope with /usr for upgrades too, OpenBSD breaks binary compatibility fairly often (mostly system call changes - at a guess roughly every 2-3 releases - and some other things like the arm and aarch64 abi change last autumn). You can't expect an old kernel to work with new userland and vice-versa. > However, Is sync or softdep a better default for the best chance of avoiding > manual fsck/support issues? Probably softdep, but it brings its own issues. Transient storage io faults (disk slow to respond) which might correct themselves without softdep often cause the machine to crash with softdep, and it has to store the filesystem changes in memory before it writes them out, which can be a problem if memory is already tight. > Turns out the issue that I had on pkg_add/ftp, that seemed to be eliminated by > switching to 3g was somehow, a short lived reprieve and was more to do with > re-assembly settings that had worked for me flawlessly, for years on a > landline. > > I believe scrub had no-df before and I am now using without issue, so far. > > set reassemble yes no-df > match scrub (random-id max-mss 1389) > > Should I drop the no-df from set reassemble? Any other recommendations > welcome? If you have mixed MTUs (e.g. forwarding packets from an ethernet interface over some ppp/vpn/encapsulated links which can't handle 1500 byte packets) then for some traffic (connecting to sites with broken firewalls that block all ICMP) you may need no-df on the scrub rule. >From the description in pf.conf(5) no-df on "set reassemble" is something else, can't say I've ever needed to use that. > Any thoughts or links on the most secure pf.conf that remains being compatible > with any network? "block" :)
Re: Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
On 2020-06-14 13:58, Kevin Chadwick wrote: > set reassemble yes no-df > match scrub (random-id max-mss 1389) > > Should I drop the no-df from set reassemble? Any other recommendations > welcome? To be clear. Previously, with scrub (no-df... the set reassemble line was missing/default.
Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
We are basing the server part of our products on OpenBSD. We care more about reducing support issues than say performance. We will have batteries but I hope to deploy some kind of root partition redundancy, for upgrades. However, Is sync or softdep a better default for the best chance of avoiding manual fsck/support issues? Turns out the issue that I had on pkg_add/ftp, that seemed to be eliminated by switching to 3g was somehow, a short lived reprieve and was more to do with re-assembly settings that had worked for me flawlessly, for years on a landline. I believe scrub had no-df before and I am now using without issue, so far. set reassemble yes no-df match scrub (random-id max-mss 1389) Should I drop the no-df from set reassemble? Any other recommendations welcome? Any thoughts or links on the most secure pf.conf that remains being compatible with any network? Thank You
Re: Optimizing pf.conf
> 6. mai 2020 kl. 22:00 skrev Lars Bonnesen : > > Is it no longer important to group block/pass in/out for speed optimization? > > I see many "modern" pf.conf where everything is mixed more or less randomly My advice would be to write your pf.conf in a way that makes sense in your environment and is readable to whoever gets to maintain the thing. As Theo pointed out, the built-in optimizer will do reordering and other tricks for performance if there is a need and you do not explicitly disable optimization. All the best, — Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. signature.asc Description: Message signed with OpenPGP
Re: Optimizing pf.conf
pfctl has an ruleset optimizer built in, which handles most of that. So, it is best if you write rules in a way that makes sense. Lars Bonnesen wrote: > Is it no longer important to group block/pass in/out for speed optimization? > > I see many "modern" pf.conf where everything is mixed more or less randomly > > Regards, Lars.
Optimizing pf.conf
Is it no longer important to group block/pass in/out for speed optimization? I see many "modern" pf.conf where everything is mixed more or less randomly Regards, Lars.
Re: pf.conf assistance
On 2020-03-27, Dirk Coetzee wrote: > Hi All, > > Without *block return label "block stateless traffic"* and *pass # establish > keep-state*, my NAT / redirect rules from external into LAN do not work. > Neither do rules that permit RDP to Windows Workstations on Tun0 interface. > FWIW: Wireguard uses this tun0 interface. Without a "block" at the top of the ruleset you're likely to have some traffic passed by the implicit default rule which is equivalent to "pass flags any no state" which will cause some confusion. You don't usually need a "pass" rule near the top though. I'd start with block, then have whatever rules you want. > TCPDump shows the destination IP sending a RST packet. Although the Internal > LAN interface shows no packet passing. That does not quite make sense to me - > but that is what happens. > > I have read online and man pages etc, and all say that the "block return" and > "pass" rules are not necessary. In fact the example given at > https://www.openbsd.org/faq/pf/filter.html does not have these two initial > rules. These default rules were carried over from the /etc/example/pf.conf The PF faq pages haven't been touched very much in years, across many major changes to PF. You're better off looking at the pf.conf(5) manual and testing.
pf.conf assistance
Hi All,
Without *block return label "block stateless traffic"* and *pass # establish
keep-state*, my NAT / redirect rules from external into LAN do not work.
Neither do rules that permit RDP to Windows Workstations on Tun0 interface.
FWIW: Wireguard uses this tun0 interface.
TCPDump shows the destination IP sending a RST packet. Although the Internal
LAN interface shows no packet passing. That does not quite make sense to me -
but that is what happens.
I have read online and man pages etc, and all say that the "block return" and
"pass" rules are not necessary. In fact the example given at
https://www.openbsd.org/faq/pf/filter.html does not have these two initial
rules. These default rules were carried over from the /etc/example/pf.conf
Event moving the *block return* default rule to lower in the rulebase - results
in the same symptoms. Syn packets pass out of Tun0 but Rst sent back almost
immediately.
Any assistance greatly appreciated. (Public IP addresses mangled. Only retained
for readability)
Regards
dirk
___
mrac-prx01# cat /etc/pf.conf
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
# ---== Skip firewalling on these interfaces ===---
set skip on { lo lo0 }
# ---=== Default Policy ===---
block return label "block stateless traffic"
block in quick log from urpf-failed # block reverse patch verify failures
block in quick log from no-route to any # block non routable traffic
block in log (all, to pflog0) # block traffic not matched explicitly
below
pass# establish keep-state
# ---=== Global Options ===---
match in all scrub (reassemble tcp no-df max-mss 1450)
match out all scrub (random-id)
set reassemble yes
set limit { tables 1 table-entries 100 states 40 frags 10
src-nodes 1 }
set block-policy drop
set loginterface pflog0
set optimization high-latency
set state-policy if-bound
set syncookies adaptive (start 25%, end 12%)
set timeout { adaptive.start 6000, adaptive.end 12000 }
set ruleset-optimization basic
set fingerprints "/etc/pf.os"
antispoof log quick for { lo0 re0 vl60 vl61 tun0 }
#antispoof log quick for em0
# ---=== Macros ===---
ext_if = "{ re0 }"
ext_ip = "{ re0:0 }"
int_if = "{ em0 }"
int_ip = "{ 192.168.50.1 192.168.50.24 }"
int_net = em0:network
tun0_if = "{ tun0 }"
tun0_ip = "{ tun0:0 }"
tun0_net = tun0:network
vl60_if = "{ vlan60 }"
vl60_ip = "{ vlan60:0 }"
vl60_net = "{ vlan60 }"
vl61_if = "{ vlan61 }"
vl61_ip = "{ vlan61:0 }"
vl61_net = "{ vlan61 }"
# ---=== Alias IP ===---
best_bme = "{ 222.172.111.114, 115.170.122.119 }"
best_knx = "{ 211.118.196.174 }"
monitoring= "{ 135.201.115.116 }"
bcastnet = "{ 192.168.50.255, 255.255.255.255, 224.0.0.0/24,
239.255.255.250, 239.255.255.253 }"
mrac_dc = "{ 192.168.50.21 }"
# ---=== Alias Protocols ===---
bcastprt = "{ 287, 68:69,137:139, 168, 546:547, 1900, 1947, 3702, 5353,
5355, 5678, 7680, 10001 }"
icmp_required = "{ echoreq, timex, paramprob, unreach code needfrag }"
# ---=== Tables ===---
table persist
table { kaspersky-labs.com }
table { wanada.epiccloud.com.au }
table persist file "/etc/pf.files/bruteforcers.txt"
table persist file "/etc/pf.files/blockedcountries.txt"
table persist file "/etc/pf.files/blockedbadhosts.txt"
# table const { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 192.168.0.0/16 198.18.0.0/15
198.51.100.0/24 203.0.113.0/24 224.0.0.0/3 }
# ---=== Block SSH Access from Abusers ===---
block quick log on any proto { tcp udp icmp } from label
"BlockSshAbusers"
# ---=== Blocked Countries and malicious hosts ===---
block quick log from label "From Blocked_Countries"
block quick log tolabel "To Blocked_Countries"
block quick log from label "From Blocked_Badhosts"
block quick log to label "To Blocked_Badhosts"
# ---=== Outbound from Firewall to anywhere on any interface ===---
block return in on ! lo0 proto tcp to port 6000:6010 # By default, do not
permit remote connections to X11
block return out log proto {tcp udp} user _pbuild # Port build user does
not need network
pass out quick on any from self to any modulate state
# ---=== Outbound Port-NAT Rules ===---
match out on $ext_if from $int_net nat-to $ext_ip source-hash
match out on $vl60_if from $int_net nat-to $ext_ip source-hash
match out on $vl61_if from $int_net nat-to $ext_ip source-hash
# ---=== Inbound
Re: using first alias as masquerading ip on pf.conf
On 2020-02-12, Sebastian Benoit wrote: > Paul de Weerd(we...@weirdnet.nl) on 2020.02.12 12:46:02 +0100: >> On Wed, Feb 12, 2020 at 12:09:12PM +0100, Federico Donati wrote: >> | Hi all, >> | >> | I have a couple of firewalls with carp configured and I need them to >> | reach the Internet even when they are in BACKUP state. >> | I'm managing pf via Ansible/GIT, so I'd like to keep the >> | configuration of pf.conf standard and simple as much as possible. >> | >> | Usually, I use the notation "nat-to ($interface)" to let pf use the >> | correct ip, but in this case I've BGP configured and the provider >> | forces me to use a complex configuration with an alias on the >> | external interface, like this: >> | >> | # ifconfig vlan835 >> | vlan835: flags=8943 mtu >> 1500 >> |lladdr b0:26:28:1e:e6:6e >> |index 13 priority 0 llprio 3 >> |encap: vnetid 835 parent trunk0 txprio packet rxprio outer >> |groups: vlan egress >> |media: Ethernet autoselect >> |status: active >> |inet 1.1.1.1 netmask 0xfff0 broadcast 1.1.1.255 >> |inet 2.2.2.2 netmask 0xfff0 broadcast 2.2.2.255 Does the 2.2.2.2 address specifically need to be on this interface (i.e. do you need to answer ARP for it)? If not then maybe you could just put it on a loopback instead (e.g. lo1) then things are simple. >> Alternatively, you could refer to a hostname that you then specify in >> /etc/hosts (with a different address on each host). > > If you dont want to go that route, you could have a file with a local > definition: > > $ cat /etc/pf/local > natip="2.2.2.2" > > $ cat /etc/pf.conf > include "/etc/pf/local" > [...] > pass in on em0 to any nat-to $natip > > Then you have pf.conf identical on both machines and /etc/pf/local per > machine (and possibly generated by ansible differently on each box). Or just use a j2 template rather than a plain copied file and set it per-host from a variable in ansible. Lots of alternatives..
Re: using first alias as masquerading ip on pf.conf
Paul de Weerd(we...@weirdnet.nl) on 2020.02.12 12:46:02 +0100: > On Wed, Feb 12, 2020 at 12:09:12PM +0100, Federico Donati wrote: > | Hi all, > | > | I have a couple of firewalls with carp configured and I need them to > | reach the Internet even when they are in BACKUP state. > | I'm managing pf via Ansible/GIT, so I'd like to keep the > | configuration of pf.conf standard and simple as much as possible. > | > | Usually, I use the notation "nat-to ($interface)" to let pf use the > | correct ip, but in this case I've BGP configured and the provider > | forces me to use a complex configuration with an alias on the > | external interface, like this: > | > | # ifconfig vlan835 > | vlan835: flags=8943 mtu 1500 > | lladdr b0:26:28:1e:e6:6e > | index 13 priority 0 llprio 3 > | encap: vnetid 835 parent trunk0 txprio packet rxprio outer > | groups: vlan egress > | media: Ethernet autoselect > | status: active > | inet 1.1.1.1 netmask 0xfff0 broadcast 1.1.1.255 > | inet 2.2.2.2 netmask 0xfff0 broadcast 2.2.2.255 > > Surely the provider doesn't force 1.1.1.1 to be the "primary" and > 2.2.2.2 to the be alias? How could they tell the difference? > > | So, 1.1.1.1 is the "transit ip" for the BGP, the one we must use to > | talk with the provider's router and that I can't use as masquerading > | ip. > | > | The ip 2.2.2.2 is the one that I should use to mask my traffic to > | the Internet, and is different on each firewall. > | > | Is there a way to tell pf to use the first alias of interface to > | mask the traffic? Something like "nat-to (vlan835:1)"... > > Could you make 1.1.1.1 the alias and 2.2.2.2 the primary address? > Then your NAT rule could simply use (vlan835:0). > > Alternatively, you could refer to a hostname that you then specify in > /etc/hosts (with a different address on each host). If you dont want to go that route, you could have a file with a local definition: $ cat /etc/pf/local natip="2.2.2.2" $ cat /etc/pf.conf include "/etc/pf/local" [...] pass in on em0 to any nat-to $natip Then you have pf.conf identical on both machines and /etc/pf/local per machine (and possibly generated by ansible differently on each box). > As far as I know, there's no way to refer to the 'first alias'. What > is the 'first alias' anyway? The first one you configured? Or the > last one? Since you're using the '(interface)' specification (with > the parentheses), you're using dynamically changing addresses .. what > does that mean in the context of 'first alias'? I would stay away from the :0 syntax as much as possible. It does not do what you think it does in IPv6, and in fact there were discussions lately to remove it completly. Even tough the ifconfig manpage and command line syntax suggests, there is no difference between primary address and aliases on an interface, it's all the same to the kernel. /Benno > | I would like to keep things simple and avoid to use the include > | directive, if possible. I think its simpler than fiddeling with /etc/hosts ;) > I tend to dislike the whole IP address "aliases" thing more and more > recently... :) > > Cheers, > > Paul 'WEiRD' de Weerd > > -- > >[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/ > --
Re: using first alias as masquerading ip on pf.conf
On Wed, Feb 12, 2020 at 12:09:12PM +0100, Federico Donati wrote: | Hi all, | | I have a couple of firewalls with carp configured and I need them to | reach the Internet even when they are in BACKUP state. | I'm managing pf via Ansible/GIT, so I'd like to keep the | configuration of pf.conf standard and simple as much as possible. | | Usually, I use the notation "nat-to ($interface)" to let pf use the | correct ip, but in this case I've BGP configured and the provider | forces me to use a complex configuration with an alias on the | external interface, like this: | | # ifconfig vlan835 | vlan835: flags=8943 mtu 1500 | lladdr b0:26:28:1e:e6:6e | index 13 priority 0 llprio 3 | encap: vnetid 835 parent trunk0 txprio packet rxprio outer | groups: vlan egress | media: Ethernet autoselect | status: active | inet 1.1.1.1 netmask 0xfff0 broadcast 1.1.1.255 | inet 2.2.2.2 netmask 0xfff0 broadcast 2.2.2.255 Surely the provider doesn't force 1.1.1.1 to be the "primary" and 2.2.2.2 to the be alias? How could they tell the difference? | So, 1.1.1.1 is the "transit ip" for the BGP, the one we must use to | talk with the provider's router and that I can't use as masquerading | ip. | | The ip 2.2.2.2 is the one that I should use to mask my traffic to | the Internet, and is different on each firewall. | | Is there a way to tell pf to use the first alias of interface to | mask the traffic? Something like "nat-to (vlan835:1)"... Could you make 1.1.1.1 the alias and 2.2.2.2 the primary address? Then your NAT rule could simply use (vlan835:0). Alternatively, you could refer to a hostname that you then specify in /etc/hosts (with a different address on each host). As far as I know, there's no way to refer to the 'first alias'. What is the 'first alias' anyway? The first one you configured? Or the last one? Since you're using the '(interface)' specification (with the parentheses), you're using dynamically changing addresses .. what does that mean in the context of 'first alias'? | I would like to keep things simple and avoid to use the include | directive, if possible. I tend to dislike the whole IP address "aliases" thing more and more recently... :) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
using first alias as masquerading ip on pf.conf
Hi all, I have a couple of firewalls with carp configured and I need them to reach the Internet even when they are in BACKUP state. I'm managing pf via Ansible/GIT, so I'd like to keep the configuration of pf.conf standard and simple as much as possible. Usually, I use the notation "nat-to ($interface)" to let pf use the correct ip, but in this case I've BGP configured and the provider forces me to use a complex configuration with an alias on the external interface, like this: # ifconfig vlan835 vlan835: flags=8943 mtu 1500 lladdr b0:26:28:1e:e6:6e index 13 priority 0 llprio 3 encap: vnetid 835 parent trunk0 txprio packet rxprio outer groups: vlan egress media: Ethernet autoselect status: active inet 1.1.1.1 netmask 0xfff0 broadcast 1.1.1.255 inet 2.2.2.2 netmask 0xfff0 broadcast 2.2.2.255 So, 1.1.1.1 is the "transit ip" for the BGP, the one we must use to talk with the provider's router and that I can't use as masquerading ip. The ip 2.2.2.2 is the one that I should use to mask my traffic to the Internet, and is different on each firewall. Is there a way to tell pf to use the first alias of interface to mask the traffic? Something like "nat-to (vlan835:1)"... I would like to keep things simple and avoid to use the include directive, if possible. Thank you for your suggestions. Bye
Re: combining macro with interface modifiers in pf.conf
Hi Philipp,
On Sat, Jan 25, 2020 at 12:06:49PM +0100, Philipp Buehler wrote:
|
| Hey Paul,
|
| Am 25.01.2020 11:43 schrieb Paul de Weerd:
| > block in on $IntIF inet proto { tcp, udp } from $IntIF:network to !
| > $IntIF:0 port domain
| > block in on $IntIF inet6 proto { tcp, udp } from $IntIF:network to !
| > $IntIF:0 port domain
|
| I just tested this with "IntIF=vio0" and works on 6.6-stable.
|
| Is there more in the story, like concat macros, quotes in quotes or
| others along that?
Thanks for your reply, you helped me find the answer. I obviously
should've published my full ruleset.
[weerd@pom] $ printf "IntIF=\"em0\"\nblock inet from \$IntIF:network to
\$IntIF:0\n" | pfctl -nvf -
IntIF = "em0"
block drop inet from 192.168.0.0/24 to 192.168.0.149
[weerd@pom] $ printf "IntIF=\" em0 \"\nblock inet from \$IntIF:network to
\$IntIF:0\n" | pfctl -nvf -
IntIF = " em0 "
stdin:2: syntax error
I have (by now 'had') spaces in my macros, so IntIF gets expanded
quite literally to the value I gave it with spaces (as it should). As
usual, PEBKAC.
Again, thank you for the clue-by-4. Everything works as it should and
I have been properly educated.
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: combining macro with interface modifiers in pf.conf
Hey Paul,
Am 25.01.2020 11:43 schrieb Paul de Weerd:
block in on $IntIF inet proto { tcp, udp } from $IntIF:network to !
$IntIF:0 port domain
block in on $IntIF inet6 proto { tcp, udp } from $IntIF:network to !
$IntIF:0 port domain
I just tested this with "IntIF=vio0" and works on 6.6-stable.
Is there more in the story, like concat macros, quotes in quotes or
others along that?
ciao
PS: tested on oldest I could find, 5.5, also works
--
pb
combining macro with interface modifiers in pf.conf
Hi all,
I'm rewriting some pf.conf rulesets and thought to use interface
modifiers to make them more generic. Here's an example of what I came
up with:
block in on $IntIF inet proto { tcp, udp } from $IntIF:network to ! $IntIF:0
port domain
block in on $IntIF inet6 proto { tcp, udp } from $IntIF:network to ! $IntIF:0
port domain
These rules force users to use the local recursor for DNS lookups.
However, pfctl complains about syntax errors on both lines. Replacing
the $IntIF:network and $IntIF:0 with em1:network and em1:0 solves the
syntax errors. From pf.conf(5), it's not quite clear to me that it
isn't allowed to combine macros with interface modifiers. On macros
it says:
> Macros can be defined that will later be expanded in context. Macro
> names must start with a letter, digit, or underscore, and may
> contain any of those characters. Macro names may not be reserved
> words (for example pass, in, out). Macros are not expanded inside
> quotes.
and on modifiers:
> Interface names, interface group names, and self can have modifiers
> appended:
To me that suggests you can combine a macro with a modifier. Am I
missing something obvious? Is there a way to achieve this?
Thanks,
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
OpenBSD 6.6-current (GENERIC.MP) #603: Mon Jan 13 13:21:42 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8478527488 (8085MB)
avail mem = 8209100800 (7828MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xec120 (49 entries)
bios0: vendor American Megatrends Inc. version "5.11" date 07/20/2018
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT CSRT
acpi0: wakeup devices SIO1(S0) BRC1(S0) XHC1(S4) HDEF(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU J3060 @ 1.60GHz, 1600.39 MHz, 06-4c-04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 80MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Celeron(R) CPU J3060 @ 1.60GHz, 1600.03 MHz, 06-4c-04
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1
mwait.1), PSS
acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1
mwait.1), PSS
acpipwrres0 at acpi0: ID3C, resource for ISP3
acpipwrres1 at acpi0: CLK0, resource for CAMD
acpipwrres2 at acpi0: CLK0, resource for CAM1
acpipwrres3 at acpi0: CLK1, resource for CAM2, CAM3
acpipwrres4 at acpi0: USBC, resource for XHC1
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 95 degC
acpicmos0 at acpi0
acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001
extent `acpipci0 pcibus' (0x0 - 0xff), flags=0
extent `acpipci0 pciio' (0x0 - 0x), flags=0
0x70 - 0x77
0xcf8 - 0xcff
0x1 - 0x
extent `acpipci0 pcimem' (0x0 - 0x), flags=0
0x0 - 0x9
0x10 - 0xafff
0xe000 - 0x
"BCM2E64" at acpi0 not configured
"BCM4752" at acpi0 not configured
"SMO91D0" at acpi0 not configured
"INTCF1C" at acpi0 not configured
acpibtn0 at acpi0: SLPB
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: using VERW MDS workaround
cpu0:
Re: pf.conf anchor directories
> hiya > can you have lines like this in pf.conf > anchor "authpf/vpn/*" in on $VPN_IFACE > anchor "authpf/wireless/*" in on $WIRE_IFACE > and have anchors in /etc/authpf/vpn with your vpn rules > and anchors in /etc/authpf/wireless with your wireless rules ? > > shadrock > To: > shadrock uhuru > CC: > misc@openbsd.org > > > yes > > Subject: > Re: pf.conf anchor directories > From: > Klemens Nanni > Date: > 8/20/19, 10:28 AM > thanks shadrock
Re: pf.conf anchor directories
yes
pf.conf anchor directories
hiya can you have lines like this in pf.conf anchor "authpf/vpn/*" in on $VPN_IFACE anchor "authpf/wireless/*" in on $WIRE_IFACE and have anchors in /etc/authpf/vpn with your vpn rules and anchors in /etc/authpf/wireless with your wireless rules ? shadrock
Re: how to use pf.conf(5) to bypass vpn based on destination port?
> All-in-all, something like that would solve that problem for you: > > pass out quick proto tcp from (self) to port 22 route-to (athn0 > $athn0_gateway) nat-to (athn0) > That worked perfectly! Thank you, Igor. Even with OpenBSD's legendary documentation at my disposal, with my current (limited) understanding of networking there is absolutely no way I would have figured that out on my own. I'm glad I asked here. Thank you so much! -Bruno
Re: how to use pf.conf(5) to bypass vpn based on destination port?
On Thu, 17 Jan 2019 at 23:24, Bruno Dantas wrote:
[...]
> pass out proto {tcp udp} to any port 22022 route-to athn0
>
> and this:
>
> pass out proto {tcp udp} to any port 22022 route-to \
> $athn0_gateway
>
> But both result in ssh authentication attempts to hang at
> "debug1: Connecting to..." then timing out.
On point-to-point links just interface name is sufficient but this is
not so with broadcast media.
Ethernet is broadcast media, thus only specifying interface would
further involve ARP to find
target node on that interface's media.
If it was an external node then no internal network node would respond
to such ARP request
-- unless it's doing Proxy ARP (which is separate subject).
For outside scope nodes proper gateways are supposed to be used
instead. Pf has to be told
which gateway it should use with given interface.
All-in-all, something like that would solve that problem for you:
pass out quick proto tcp from (self) to port 22 route-to (athn0
$athn0_gateway) nat-to (athn0)
More clearer design would be based on separate routing tables though.
--
End of message. Next message?
how to use pf.conf(5) to bypass vpn based on destination port?
My personal laptop runs OpenBSD 6.4. I browse the web using WiFi +
openvpn client for added privacy. The default behavior of all outgoing
traffic going through VPN is generally desirable, but I need some
outgoing packets (e.g., ssh traffic) to bypass VPN--i.e., those packets
should go out via default gateway of my wireless card (athn0), not via
tun0. My machines running ssh servers connect to internet via ISP,
are not running VPN client or server, and listen on port 22022.
Back in my Linux days, I used iptables(8) to put a mark on the packets
that should bypass vpn, then used ip(8) to create a custom route for
the marked packets, like this:
iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 22022 -j \
MARK --set-mark 1
ip route add table 100 $wlan0_default_gateway
ip rule add fwmark 1 table 10
Please, how do I accomplish this on OpenBSD 6.4 using pf.conf(5)?
I already tried various permutations of this:
pass out proto {tcp udp} to any port 22022 route-to athn0
and this:
pass out proto {tcp udp} to any port 22022 route-to \
$athn0_gateway
But both result in ssh authentication attempts to hang at
"debug1: Connecting to..." then timing out.
jggimi at daemonforums.org tried to help but we couldn't figure it out,
so he suggested that I ask for help here. The thread of our attempt is
here (I didn't mention that I use port 22022 instead of 22 because
I don't think it really matters):
http://daemonforums.org/showthread.php?t=10905
I can bypass VPN to reach an *individual* ssh server with this:
athn0_gateway=$(route show | grep default | awk '{print $2}')
route add $ssh_server_ip $athn0_gateway
but I'd really like to learn how to accomplish this using pf.conf(5)
so that I can bypass VPN based on destination port instead of
destination ip address, thereby having an elegant solution that works
for all ssh servers.
Please help me.
Thank you,
Bruno Dantas
Re: iked : pf.conf rule for outgoing traffic
* Stuart Henderson le [10-12-2018 18:19:41 +]: > On 2018-12-07, Thuban wrote: > > * Stuart Henderson le [06-12-2018 13:44:50 +]: > >> On 2018-12-06, Thuban wrote: > >> > * Thuban le [02-12-2018 19:16:09 +0100]: > >> >> Hi, > >> >> I need help to write a correct rule in pf.conf. > >> >> > >> >> I want : > >> >> > >> >> A -> B --> web > >> >> > >> >> The appearing IP of A is the B's one on the web. > >> >> > >> >> I managed to configure iked on A and B using default pubkeys according > >> >> to Stuart Henderson advices. > >> >> > >> >> iked.conf on A : > >> >> > >> >> ikev2 active ipcomp esp \ > >> >> from 192.168.100.0/16 to 0.0.0.0/0 \ > >> >> peer "xx.xx.xx.xx" \ > >> >> srcid "m...@moria.lan" \ > >> >> dstid "B-hostname.tld" \ > >> >> tag IKED > >> >> > >> >> iked.conf on B : > >> >> > >> >> ikev2 "warrior" passive esp \ > >> >> from 0.0.0.0/0 to 0.0.0.0/0 \ > >> >> local xx.xx.xx.xx peer any \ > >> >> srcid "B-hostname.tld" \ > >> >> tag IKED > >> >> > >> >> Auth works as expected : > >> >> > >> >> # iked -vvd > >> >> .. > >> >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to > >> >> 192.168.100.122:4500 policy 'policy1' > >> >> .. > >> >> > >> >> > >> >> But I can't reach internet from A through B. > >> >> > >> >> Here is the pf.conf on B (at least a small part of it) > >> >> > >> >> pass out on egress \ > >> >> from any to any tagged IKED \ > >> >> nat-to (egress) > >> >> > >> >> > >> > > >> > I'm still stuck at the same point. > >> > Can someone give me an example of a working configuration natting ot > >> > Internet? > >> > >> I used this, > >> > >> pass in on enc0 inet from $some_net > >> pass out quick on egress inet received-on enc0 nat-to $some_address > >> > >> Also I don't remember what you've already said you checked, but > >> make sure you have sysctl net.inet.ip.forwarding=1. > >> > > > > Thank you. > > Yes, I do have ip.forwarding=1. > > > > I'm confused how to replace "$some_address". Isn't it "(egress)" ? > > > > Regards. > > > > > > It depends on what you want - I was just giving you the working example > you asked for :-) > > in my case I want to nat to a specific address, and not track the > address/es on any egress interfaces. > > Okay, got it, it works as expected. Thank you :)
Re: iked : pf.conf rule for outgoing traffic
On 2018-12-07, Thuban wrote: > * Stuart Henderson le [06-12-2018 13:44:50 +]: >> On 2018-12-06, Thuban wrote: >> > * Thuban le [02-12-2018 19:16:09 +0100]: >> >> Hi, >> >> I need help to write a correct rule in pf.conf. >> >> >> >> I want : >> >> >> >> A -> B --> web >> >> >> >> The appearing IP of A is the B's one on the web. >> >> >> >> I managed to configure iked on A and B using default pubkeys according >> >> to Stuart Henderson advices. >> >> >> >> iked.conf on A : >> >> >> >> ikev2 active ipcomp esp \ >> >> from 192.168.100.0/16 to 0.0.0.0/0 \ >> >> peer "xx.xx.xx.xx" \ >> >> srcid "m...@moria.lan" \ >> >> dstid "B-hostname.tld" \ >> >> tag IKED >> >> >> >> iked.conf on B : >> >> >> >> ikev2 "warrior" passive esp \ >> >> from 0.0.0.0/0 to 0.0.0.0/0 \ >> >> local xx.xx.xx.xx peer any \ >> >> srcid "B-hostname.tld" \ >> >> tag IKED >> >> >> >> Auth works as expected : >> >> >> >> # iked -vvd >> >> .. >> >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to >> >> 192.168.100.122:4500 policy 'policy1' >> >> .. >> >> >> >> >> >> But I can't reach internet from A through B. >> >> >> >> Here is the pf.conf on B (at least a small part of it) >> >> >> >> pass out on egress \ >> >> from any to any tagged IKED \ >> >> nat-to (egress) >> >> >> >> >> > >> > I'm still stuck at the same point. >> > Can someone give me an example of a working configuration natting ot >> > Internet? >> >> I used this, >> >> pass in on enc0 inet from $some_net >> pass out quick on egress inet received-on enc0 nat-to $some_address >> >> Also I don't remember what you've already said you checked, but >> make sure you have sysctl net.inet.ip.forwarding=1. >> > > Thank you. > Yes, I do have ip.forwarding=1. > > I'm confused how to replace "$some_address". Isn't it "(egress)" ? > > Regards. > > It depends on what you want - I was just giving you the working example you asked for :-) in my case I want to nat to a specific address, and not track the address/es on any egress interfaces.
Re: iked : pf.conf rule for outgoing traffic
> I'm confused how to replace "$some_address". Isn't it "(egress)" ? "(egress)" or your_WAN_IP On Fri, 7 Dec 2018 10:00:07 +0100 Thuban wrote: > * Stuart Henderson le [06-12-2018 13:44:50 +]: > > On 2018-12-06, Thuban wrote: > > > * Thuban le [02-12-2018 19:16:09 +0100]: > > >> Hi, > > >> I need help to write a correct rule in pf.conf. > > >> > > >> I want : > > >> > > >> A -> B --> web > > >> > > >> The appearing IP of A is the B's one on the web. > > >> > > >> I managed to configure iked on A and B using default pubkeys according > > >> to Stuart Henderson advices. > > >> > > >> iked.conf on A : > > >> > > >> ikev2 active ipcomp esp \ > > >> from 192.168.100.0/16 to 0.0.0.0/0 \ > > >> peer "xx.xx.xx.xx" \ > > >> srcid "m...@moria.lan" \ > > >> dstid "B-hostname.tld" \ > > >> tag IKED > > >> > > >> iked.conf on B : > > >> > > >> ikev2 "warrior" passive esp \ > > >> from 0.0.0.0/0 to 0.0.0.0/0 \ > > >> local xx.xx.xx.xx peer any \ > > >> srcid "B-hostname.tld" \ > > >> tag IKED > > >> > > >> Auth works as expected : > > >> > > >> # iked -vvd > > >> .. > > >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to > > >> 192.168.100.122:4500 policy 'policy1' > > >> .. > > >> > > >> > > >> But I can't reach internet from A through B. > > >> > > >> Here is the pf.conf on B (at least a small part of it) > > >> > > >> pass out on egress \ > > >> from any to any tagged IKED \ > > >> nat-to (egress) > > >> > > >> > > > > > > I'm still stuck at the same point. > > > Can someone give me an example of a working configuration natting ot > > > Internet? > > > > I used this, > > > > pass in on enc0 inet from $some_net > > pass out quick on egress inet received-on enc0 nat-to $some_address > > > > Also I don't remember what you've already said you checked, but > > make sure you have sysctl net.inet.ip.forwarding=1. > > > > Thank you. > Yes, I do have ip.forwarding=1. > > I'm confused how to replace "$some_address". Isn't it "(egress)" ? > > Regards. > -- radek
Re: iked : pf.conf rule for outgoing traffic
* Stuart Henderson le [06-12-2018 13:44:50 +]: > On 2018-12-06, Thuban wrote: > > * Thuban le [02-12-2018 19:16:09 +0100]: > >> Hi, > >> I need help to write a correct rule in pf.conf. > >> > >> I want : > >> > >> A -> B --> web > >> > >> The appearing IP of A is the B's one on the web. > >> > >> I managed to configure iked on A and B using default pubkeys according > >> to Stuart Henderson advices. > >> > >> iked.conf on A : > >> > >>ikev2 active ipcomp esp \ > >>from 192.168.100.0/16 to 0.0.0.0/0 \ > >>peer "xx.xx.xx.xx" \ > >>srcid "m...@moria.lan" \ > >>dstid "B-hostname.tld" \ > >>tag IKED > >> > >> iked.conf on B : > >> > >>ikev2 "warrior" passive esp \ > >>from 0.0.0.0/0 to 0.0.0.0/0 \ > >>local xx.xx.xx.xx peer any \ > >>srcid "B-hostname.tld" \ > >>tag IKED > >> > >> Auth works as expected : > >> > >> # iked -vvd > >> .. > >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to > >> 192.168.100.122:4500 policy 'policy1' > >> .. > >> > >> > >> But I can't reach internet from A through B. > >> > >> Here is the pf.conf on B (at least a small part of it) > >> > >> pass out on egress \ > >> from any to any tagged IKED \ > >> nat-to (egress) > >> > >> > > > > I'm still stuck at the same point. > > Can someone give me an example of a working configuration natting ot > > Internet? > > I used this, > > pass in on enc0 inet from $some_net > pass out quick on egress inet received-on enc0 nat-to $some_address > > Also I don't remember what you've already said you checked, but > make sure you have sysctl net.inet.ip.forwarding=1. > Thank you. Yes, I do have ip.forwarding=1. I'm confused how to replace "$some_address". Isn't it "(egress)" ? Regards.
Re: iked : pf.conf rule for outgoing traffic
On 2018-12-06, Thuban wrote: > * Thuban le [02-12-2018 19:16:09 +0100]: >> Hi, >> I need help to write a correct rule in pf.conf. >> >> I want : >> >> A -> B --> web >> >> The appearing IP of A is the B's one on the web. >> >> I managed to configure iked on A and B using default pubkeys according >> to Stuart Henderson advices. >> >> iked.conf on A : >> >> ikev2 active ipcomp esp \ >> from 192.168.100.0/16 to 0.0.0.0/0 \ >> peer "xx.xx.xx.xx" \ >> srcid "m...@moria.lan" \ >> dstid "B-hostname.tld" \ >> tag IKED >> >> iked.conf on B : >> >> ikev2 "warrior" passive esp \ >> from 0.0.0.0/0 to 0.0.0.0/0 \ >> local xx.xx.xx.xx peer any \ >> srcid "B-hostname.tld" \ >> tag IKED >> >> Auth works as expected : >> >> # iked -vvd >> .. >> sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to 192.168.100.122:4500 >> policy 'policy1' >> .. >> >> >> But I can't reach internet from A through B. >> >> Here is the pf.conf on B (at least a small part of it) >> >> pass out on egress \ >> from any to any tagged IKED \ >> nat-to (egress) >> >> > > I'm still stuck at the same point. > Can someone give me an example of a working configuration natting ot > Internet? I used this, pass in on enc0 inet from $some_net pass out quick on egress inet received-on enc0 nat-to $some_address Also I don't remember what you've already said you checked, but make sure you have sysctl net.inet.ip.forwarding=1.
Re: iked : pf.conf rule for outgoing traffic
* Thuban le [02-12-2018 19:16:09 +0100]: > Hi, > I need help to write a correct rule in pf.conf. > > I want : > > A -> B --> web > > The appearing IP of A is the B's one on the web. > > I managed to configure iked on A and B using default pubkeys according > to Stuart Henderson advices. > > iked.conf on A : > > ikev2 active ipcomp esp \ > from 192.168.100.0/16 to 0.0.0.0/0 \ > peer "xx.xx.xx.xx" \ > srcid "m...@moria.lan" \ > dstid "B-hostname.tld" \ > tag IKED > > iked.conf on B : > > ikev2 "warrior" passive esp \ > from 0.0.0.0/0 to 0.0.0.0/0 \ > local xx.xx.xx.xx peer any \ > srcid "B-hostname.tld" \ > tag IKED > > Auth works as expected : > > # iked -vvd > .. > sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to 192.168.100.122:4500 > policy 'policy1' > .. > > > But I can't reach internet from A through B. > > Here is the pf.conf on B (at least a small part of it) > > pass out on egress \ > from any to any tagged IKED \ > nat-to (egress) > > I'm still stuck at the same point. Can someone give me an example of a working configuration natting ot Internet? Regards.
iked : pf.conf rule for outgoing traffic
Hi,
I need help to write a correct rule in pf.conf.
I want :
A -> B --> web
The appearing IP of A is the B's one on the web.
I managed to configure iked on A and B using default pubkeys according
to Stuart Henderson advices.
iked.conf on A :
ikev2 active ipcomp esp \
from 192.168.100.0/16 to 0.0.0.0/0 \
peer "xx.xx.xx.xx" \
srcid "m...@moria.lan" \
dstid "B-hostname.tld" \
tag IKED
iked.conf on B :
ikev2 "warrior" passive esp \
from 0.0.0.0/0 to 0.0.0.0/0 \
local xx.xx.xx.xx peer any \
srcid "B-hostname.tld" \
tag IKED
Auth works as expected :
# iked -vvd
...
sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to 192.168.100.122:4500
policy 'policy1'
...
But I can't reach internet from A through B.
Here is the pf.conf on B (at least a small part of it)
pass out on egress \
from any to any tagged IKED \
nat-to (egress)
I guess the issue is in my pf.conf.
What do you think ?
Any advice?
Regards.
--
thuban
Re: pf.conf: identifying a specific user from dhcpd-table
On 2018-10-10, Stefan Wollny wrote: > I could assign a static address to this laptop and use this address > setting up a specific rule for this one port. But this is not the way > I'd prefer to go. Note that, doing it this way, if the server's dynamic address changes client connections will need to timeout before they can reconnect and get redirected to the server's new address. Would DHCP with fixed-address not work here?
Re: pf.conf: identifying a specific user from dhcpd-table
On Oct 10, 2018 10:23 AM, Paul de Weerd wrote: > > On Wed, Oct 10, 2018 at 10:17:21AM -0500, Edgar Pettijohn wrote: > | When looking for pf info I generally just Google Peter Hansteen. > > So is Peter misnamed, should he be called Peter Fansteen, or is pf(4) > misnamed, should it be ph(4)? > We should let him choose, but Peter fansteen has a nice ring to it. Edgar > *confused* > > Paul 'WEiRD' de Weerd > > SCNR > > -- > >[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/
Re: pf.conf: identifying a specific user from dhcpd-table
On Wed, Oct 10, 2018 at 10:17:21AM -0500, Edgar Pettijohn wrote: | When looking for pf info I generally just Google Peter Hansteen. So is Peter misnamed, should he be called Peter Fansteen, or is pf(4) misnamed, should it be ph(4)? *confused* Paul 'WEiRD' de Weerd SCNR -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: pf.conf: identifying a specific user from dhcpd-table
Edgar,
Sounds like you need to build an adaptive firewall. I would suggest to start
with The Book of PF
by Peter Hansteen. An excellent resource. That might be a good starting point
for you as well.
It has some good portion of the information on adaptive firewalls.
P.S. Thank you, Peter for such a great book.
-bogdan
> On Oct 10, 2018, at 8:17 AM, Edgar Pettijohn wrote:
>
>
> On Oct 10, 2018 7:58 AM, "Peter N. M. Hansteen" wrote:
>>
>> On Wed, Oct 10, 2018 at 02:48:24PM +0200, Stefan Wollny wrote:
>>>
>>> I'd like to set up PF to forward this port (25565) without a pre-defined
>>> IP as macro as the dhcpd.conf has a line defining tables for abandoned
>>> ("-A"), changed ("-C") and present leases ("-L"). According to man
>>> dhcpd(8) those tables may be used with PF. But how??? I couldn't find
>>> examples.
>>>
>>> Do I have to tell PF about these tables in pf.conf? Or don't I need
>>> these tables at all?
>>
>> You do need to include the tables in your pf.conf. I'm a bit surprised
>> the example at https://home.nuug.no/~peter/pftutorial/#33 did not show up in
>> your search.
>>
>> - P
>>
>> --
>> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
>> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
>> "Remember to set the evil bit on all malicious network traffic"
>> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>>
>
> When looking for pf info I generally just Google Peter Hansteen.
>
> Edgar
>
Re: pf.conf: identifying a specific user from dhcpd-table
On Oct 10, 2018 7:58 AM, "Peter N. M. Hansteen" wrote:
>
> On Wed, Oct 10, 2018 at 02:48:24PM +0200, Stefan Wollny wrote:
> >
> > I'd like to set up PF to forward this port (25565) without a pre-defined
> > IP as macro as the dhcpd.conf has a line defining tables for abandoned
> > ("-A"), changed ("-C") and present leases ("-L"). According to man
> > dhcpd(8) those tables may be used with PF. But how??? I couldn't find
> > examples.
> >
> > Do I have to tell PF about these tables in pf.conf? Or don't I need
> > these tables at all?
>
> You do need to include the tables in your pf.conf. I'm a bit surprised
> the example at https://home.nuug.no/~peter/pftutorial/#33 did not show up in
> your search.
>
> - P
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
When looking for pf info I generally just Google Peter Hansteen.
Edgar
Re: pf.conf: identifying a specific user from dhcpd-table
Am 10.10.18 um 14:58 schrieb Peter N. M. Hansteen:
> On Wed, Oct 10, 2018 at 02:48:24PM +0200, Stefan Wollny wrote:
>>
>> I'd like to set up PF to forward this port (25565) without a pre-defined
>> IP as macro as the dhcpd.conf has a line defining tables for abandoned
>> ("-A"), changed ("-C") and present leases ("-L"). According to man
>> dhcpd(8) those tables may be used with PF. But how??? I couldn't find
>> examples.
>>
>> Do I have to tell PF about these tables in pf.conf? Or don't I need
>> these tables at all?
>
> You do need to include the tables in your pf.conf. I'm a bit surprised
> the example at https://home.nuug.no/~peter/pftutorial/#33 did not show up in
> your search.
>
> - P
>
YES - this is exactly what I've been looking for!
(I use Google via 'startpage.com' - maybe this makes a difference???)
Thank you very much, Peter. BTW: Am I this blind that I oversaw this in
your book??? I had it with me on the train yesterday but I didn't see
this solution. Will take a 20th look tonight.
'Thank you' again for so much help here on the list, but as well for the
fine book!
Best,
STEFAN
Re: pf.conf: identifying a specific user from dhcpd-table
On Wed, Oct 10, 2018 at 02:48:24PM +0200, Stefan Wollny wrote:
>
> I'd like to set up PF to forward this port (25565) without a pre-defined
> IP as macro as the dhcpd.conf has a line defining tables for abandoned
> ("-A"), changed ("-C") and present leases ("-L"). According to man
> dhcpd(8) those tables may be used with PF. But how??? I couldn't find
> examples.
>
> Do I have to tell PF about these tables in pf.conf? Or don't I need
> these tables at all?
You do need to include the tables in your pf.conf. I'm a bit surprised
the example at https://home.nuug.no/~peter/pftutorial/#33 did not show up in
your search.
- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
pf.conf: identifying a specific user from dhcpd-table
Hi there!
I've google'd quite a while and read the FAQ and many man-pages - but I
didn't find an example for my pf.conf (or simply overlooked it...):
The system is amd64-current. The client is Win7-laptop serving as
Minecraft-server, thus port 25565 needs to be forwarded but IP may change.
I have set up OpenBSD as firewall-router serving additionally as
dhcpd-server plus running a transparent squid. IP-forwarding is set in
/etc/sysctl. Basically everything is running fine, my users surf the net
and send/receive mail. Just that the other kids cannot reach my son's
Minecraft-server on the inside from the outside.
I could assign a static address to this laptop and use this address
setting up a specific rule for this one port. But this is not the way
I'd prefer to go.
I'd like to set up PF to forward this port (25565) without a pre-defined
IP as macro as the dhcpd.conf has a line defining tables for abandoned
("-A"), changed ("-C") and present leases ("-L"). According to man
dhcpd(8) those tables may be used with PF. But how??? I couldn't find
examples.
Do I have to tell PF about these tables in pf.conf? Or don't I need
these tables at all?
What would the syntax actually be for the dhcpd-client (e.g.'enderman'),
s.th like the following tries?
pass on $ext_if from $int_if:peer to any binat-to $ext_if port 25565
This is not specific to client 'enderman'... another try:
pass out on $ext_if inet from $int_if to any \
nat-to enderman:peer static-port
pass in on $ext_if inet from any to $int_if rdr-to enderman:peer
This rule is not specific to port 25565, though.
Please help - I am pretty confused...
TIA.
Best,
STEFAN
Re: Interface modifiers in pf.conf
On Thu, Sep 27, 2018, 3:59 AM Per-Olov Sjöholm, wrote: > On Thu, Sep 27, 2018, at 06:16, Theo de Raadt wrote: > > =?utf-8?Q?Per-Olov=20Sj=C3=B6holm?= wrote: > > > > > I can in the man page fr PF see: > > > > > > --snip-- > > > Interface names, interface group names, and self can have > > > modifiers appended: > > > > > > :0 Do not include interface aliases. > > > :broadcast Translates to the interface's broadcast > address(es). > > > :networkTranslates to the network(s) attached to the > > > interface. > > > :peer Translates to the point-to-point interface's > peer > > > address(es). > > > --snip-- > > > > > > Is there a special reason syntax like INTERNET_INT:1 wont work if we > want to use the first alias address from the hostname interface file? > > > > > > As it is now I have to use the base adress by using ":0" or including > all aliases. For me this seems unusable. If I want to nat out on the alias > address from for example the DMZ I would like to use ":1". As this is not > possible I have to hard code the IP:s in pf.conf. > > > > Yes there is a very good reason. > > > > Interface aliases are not what you think they. A mistake was made > > more than two decades ago. If you reconfigure, they "roll". > > > > You should avoid use of :0, unless you need it. But definately you do > > not want :1 or :2 etc > > > Ahhh I see... Didn't know that. Many thanks for the answer > > I found it very convenient to not add the external IP into pf.conf, but > let the service itself harvest it from the interface. But it seems it is no > longer possible when you add more IPs to the external interface (unless you > want them all in the same rule of course). Not a biggie. Just interested to > see if it is possible to have more than one IP on the interface and don't > have them specified in pf.conf... > > How would you solve this example below Should I hard code the IPs and only > use these and skip usage of ":0" in this case? Is there maybe a way to > instead create a separate sub interface for the alias IP so the sub > interface could be used in PF, but the resulting PF behaviour remains? > > cat /etc/hostname.ix3 > inet 192.168.0.100 255.255.255.0 192.168.0.255 description "INTERNET > UPLINK TEST" > !ifconfig ix3 inet alias 192.168.0.101 netmask 255.255.255.255 broadcast > 192.168.0.255 > > > From pf.conf example > INTERNET_INT="ix3" > INTERNET_INT_IP1="192.168.0.100" <<< Can this be avoided? > INTERNET_INT_IP2="192.168.0.102" <<< Can this be avoided? > match out on $INTERNET_INT from $DMZ1_DAEDALUS to any nat-to > $INTERNET_INT_IP2 > match out on $INTERNET_INT from $LAN_INT:network to any nat-to > $INTERNET_INT:0 Instead of making alias interfaces, you could always make carp interfaces I guess. Then your pf.conf could be like: INTERNET_INT="ix3" INTERNET_INT_IF2="carp100" match out on $INTERNET_INT from $DMZ1_DAEDALUS to any nat-to $INTERNET_INT_IF2 match out on $INTERNET_INT from $LAN_INT:network to any nat-to $INTERNET_INT:0
Re: Interface modifiers in pf.conf
On Thu, Sep 27, 2018, at 06:16, Theo de Raadt wrote: > =?utf-8?Q?Per-Olov=20Sj=C3=B6holm?= wrote: > > > I can in the man page fr PF see: > > > > --snip-- > > Interface names, interface group names, and self can have > > modifiers appended: > > > > :0 Do not include interface aliases. > > :broadcast Translates to the interface's broadcast > > address(es). > > :networkTranslates to the network(s) attached to the > > interface. > > :peer Translates to the point-to-point interface's peer > > address(es). > > --snip-- > > > > Is there a special reason syntax like INTERNET_INT:1 wont work if we want > > to use the first alias address from the hostname interface file? > > > > As it is now I have to use the base adress by using ":0" or including all > > aliases. For me this seems unusable. If I want to nat out on the alias > > address from for example the DMZ I would like to use ":1". As this is not > > possible I have to hard code the IP:s in pf.conf. > > Yes there is a very good reason. > > Interface aliases are not what you think they. A mistake was made > more than two decades ago. If you reconfigure, they "roll". > > You should avoid use of :0, unless you need it. But definately you do > not want :1 or :2 etc Ahhh I see... Didn't know that. Many thanks for the answer I found it very convenient to not add the external IP into pf.conf, but let the service itself harvest it from the interface. But it seems it is no longer possible when you add more IPs to the external interface (unless you want them all in the same rule of course). Not a biggie. Just interested to see if it is possible to have more than one IP on the interface and don't have them specified in pf.conf... How would you solve this example below Should I hard code the IPs and only use these and skip usage of ":0" in this case? Is there maybe a way to instead create a separate sub interface for the alias IP so the sub interface could be used in PF, but the resulting PF behaviour remains? cat /etc/hostname.ix3 inet 192.168.0.100 255.255.255.0 192.168.0.255 description "INTERNET UPLINK TEST" !ifconfig ix3 inet alias 192.168.0.101 netmask 255.255.255.255 broadcast 192.168.0.255 >From pf.conf example INTERNET_INT="ix3" INTERNET_INT_IP1="192.168.0.100" <<< Can this be avoided? INTERNET_INT_IP2="192.168.0.102" <<< Can this be avoided? match out on $INTERNET_INT from $DMZ1_DAEDALUS to any nat-to $INTERNET_INT_IP2 match out on $INTERNET_INT from $LAN_INT:network to any nat-to $INTERNET_INT:0 Tnx Peo
Re: Interface modifiers in pf.conf
=?utf-8?Q?Per-Olov=20Sj=C3=B6holm?= wrote: > I can in the man page f??r PF see: > > --snip-- > Interface names, interface group names, and self can have > modifiers appended: > > :0 Do not include interface aliases. > :broadcast Translates to the interface's broadcast address(es). > :networkTranslates to the network(s) attached to the > interface. > :peer Translates to the point-to-point interface's peer > address(es). > --snip-- > > Is there a special reason syntax like INTERNET_INT:1 wont work if we want to > use the first alias address from the hostname interface file? > > As it is now I have to use the base adress by using ":0" or including all > aliases. For me this seems unusable. If I want to nat out on the alias > address from for example the DMZ I would like to use ":1". As this is not > possible I have to hard code the IP:s in pf.conf. Yes there is a very good reason. Interface aliases are not what you think they. A mistake was made more than two decades ago. If you reconfigure, they "roll". You should avoid use of :0, unless you need it. But definately you do not want :1 or :2 etc
Interface modifiers in pf.conf
Hi I can in the man page för PF see: --snip-- Interface names, interface group names, and self can have modifiers appended: :0 Do not include interface aliases. :broadcast Translates to the interface's broadcast address(es). :networkTranslates to the network(s) attached to the interface. :peer Translates to the point-to-point interface's peer address(es). --snip-- Is there a special reason syntax like INTERNET_INT:1 wont work if we want to use the first alias address from the hostname interface file? As it is now I have to use the base adress by using ":0" or including all aliases. For me this seems unusable. If I want to nat out on the alias address from for example the DMZ I would like to use ":1". As this is not possible I have to hard code the IP:s in pf.conf. Have I misunderstood something? Please enlighten me. Tnx Peo
Re: pf.conf "reply-to" routing parameter seemingly not working?
Apologies, correction: obsd3# pfctl -f /etc/pf.conf Should be: obsd2# pfctl -f /etc/pf.conf Joe On Sat, May 12, 2018 at 9:37 PM Joseph Crivello <josephcrive...@gmail.com> wrote: > I cannot get reply-to working with if-bound under any circumstances. It > works fine with floating, though. > Is this expected behavior? The (similar) route-to option works fine with > if-bound rules, and I cannot find any documentation that states reply-to > cannot be used with if-bound rules. > Assuming that this is NOT expected behavior, then this is a bug in at least > 6.2 through -current. > I set up three virtual machines running -current today, in order to > reproduce this with a basic test case: > obsd1# echo "inet 10.84.31.10 255.255.255.0" > /etc/hostname.vmx1 > obsd1# echo "inet 10.84.32.10 255.255.255.0" > /etc/hostname.vmx2 > obsd1# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf > obsd1# reboot > ... > obsd1# route add -net 10.84.33.0/24 10.84.31.11 > obsd2# echo "inet 10.84.31.11 255.255.255.0" > /etc/hostname.vmx1 > obsd2# echo "inet 10.84.32.11 255.255.255.0" > /etc/hostname.vmx2 > obsd2# echo "inet 10.84.33.11 255.255.255.0" > /etc/hostname.vmx3 > obsd2# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf > obsd2# reboot > ... > obsd2# echo "pass in log on vmx1 inet from 10.84.31.10 to 10.84.33.12 keep > state (if-bound) reply-to 10.84.32.10@vmx2" >> /etc/pf.conf > obsd3# pfctl -f /etc/pf.conf > Host "obsd3" has just one interface, with IP 10.84.33.12. > No other changes were made to the hosts besides selecting typical > installation options. > If we test this setup with an ICMP echo to 10.84.33.12 from obsd1, here is > what we observe: > obsd1# ping -c 1 10.84.33.12 > PING 10.84.33.12 (10.84.33.12): 56 data bytes > ^C > --- 10.84.33.12 ping statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > obsd2# tcpdump -nvvpi vmx1 icmp > tcpdump: listening on vmx1, link-type EN10MB > 21:20:08.710088 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e > seq:0) [icmp cksum ok] (ttl 255, id 23663, len 84) > ^C > 1 packets received by filter > 0 packets dropped by kernel > obsd2# tcpdump -nvvpi vmx2 icmp > tcpdump: listening on vmx2, link-type EN10MB > ^C > 0 packets received by filter > 0 packets dropped by kernel > obsd2# tcpdump -nvvpi vmx3 icmp > tcpdump: listening on vmx3, link-type EN10MB > 21:20:08.710136 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e > seq:0) [icmp cksum ok] (ttl 254, id 23663, len 84) > 21:20:08.710249 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:306e seq:0) > [icmp cksum ok] (ttl 255, id 8694, len 84) > 21:20:08.710272 10.84.33.11 > 10.84.33.12: icmp: 10.84.31.10 protocol 1 > port 40981 unreachable [icmp cksum ok] for 10.84.33.12 > 10.84.31.10: icmp: > echo reply (id:306e seq:0) (ttl 254, id 8694, len 84, bad ip cksum 44f5! -> > 45f5) (ttl 255, id 637, len 56) > ^C > 3 packets received by filter > 0 packets dropped by kernel > If we change the PF rule we created on obsd2 to "floating" and run the same > test again, then the test case works exactly as expected: > obsd1# ping -c 1 10.84.33.12 > PING 10.84.33.12 (10.84.33.12): 56 data bytes > 64 bytes from 10.84.33.12: icmp_seq=0 ttl=254 time=0.528 ms > --- 10.84.33.12 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 0.528/0.528/0.528/0.000 ms > obsd2# tcpdump -nvvpi vmx1 icmp > tcpdump: listening on vmx1, link-type EN10MB > 21:25:24.970742 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec > seq:0) [icmp cksum ok] (ttl 255, id 27013, len 84) > ^C > 1 packets received by filter > 0 packets dropped by kernel > obsd2# tcpdump -nvvpi vmx2 icmp > tcpdump: listening on vmx2, link-type EN10MB > 21:25:24.971146 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec seq:0) > [icmp cksum ok] (ttl 254, id 13581, len 84) > ^C > 3 packets received by filter > 0 packets dropped by kernel > obsd2# tcpdump -nvvpi vmx3 icmp > tcpdump: listening on vmx3, link-type EN10MB > 21:25:24.970800 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec > seq:0) [icmp cksum ok] (ttl 254, id 27013, len 84) > 21:25:24.970933 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec seq:0) > [icmp cksum ok] (ttl 255, id 13581, len 84) > ^C > 2 packets received by filter > 0 packets dropped by kernel > I am interested in any feedback on the question of whether or not this is > expected behavior... > Thank you. > Joe > On Thu, May 10, 2018 at 1:50 AM Joe Crivello <josephcrive...@gmail.com> > wrote:
Re: pf.conf "reply-to" routing parameter seemingly not working?
I cannot get reply-to working with if-bound under any circumstances. It works fine with floating, though. Is this expected behavior? The (similar) route-to option works fine with if-bound rules, and I cannot find any documentation that states reply-to cannot be used with if-bound rules. Assuming that this is NOT expected behavior, then this is a bug in at least 6.2 through -current. I set up three virtual machines running -current today, in order to reproduce this with a basic test case: obsd1# echo "inet 10.84.31.10 255.255.255.0" > /etc/hostname.vmx1 obsd1# echo "inet 10.84.32.10 255.255.255.0" > /etc/hostname.vmx2 obsd1# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf obsd1# reboot ... obsd1# route add -net 10.84.33.0/24 10.84.31.11 obsd2# echo "inet 10.84.31.11 255.255.255.0" > /etc/hostname.vmx1 obsd2# echo "inet 10.84.32.11 255.255.255.0" > /etc/hostname.vmx2 obsd2# echo "inet 10.84.33.11 255.255.255.0" > /etc/hostname.vmx3 obsd2# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf obsd2# reboot ... obsd2# echo "pass in log on vmx1 inet from 10.84.31.10 to 10.84.33.12 keep state (if-bound) reply-to 10.84.32.10@vmx2" >> /etc/pf.conf obsd3# pfctl -f /etc/pf.conf Host "obsd3" has just one interface, with IP 10.84.33.12. No other changes were made to the hosts besides selecting typical installation options. If we test this setup with an ICMP echo to 10.84.33.12 from obsd1, here is what we observe: obsd1# ping -c 1 10.84.33.12 PING 10.84.33.12 (10.84.33.12): 56 data bytes ^C --- 10.84.33.12 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss obsd2# tcpdump -nvvpi vmx1 icmp tcpdump: listening on vmx1, link-type EN10MB 21:20:08.710088 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e seq:0) [icmp cksum ok] (ttl 255, id 23663, len 84) ^C 1 packets received by filter 0 packets dropped by kernel obsd2# tcpdump -nvvpi vmx2 icmp tcpdump: listening on vmx2, link-type EN10MB ^C 0 packets received by filter 0 packets dropped by kernel obsd2# tcpdump -nvvpi vmx3 icmp tcpdump: listening on vmx3, link-type EN10MB 21:20:08.710136 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e seq:0) [icmp cksum ok] (ttl 254, id 23663, len 84) 21:20:08.710249 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:306e seq:0) [icmp cksum ok] (ttl 255, id 8694, len 84) 21:20:08.710272 10.84.33.11 > 10.84.33.12: icmp: 10.84.31.10 protocol 1 port 40981 unreachable [icmp cksum ok] for 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:306e seq:0) (ttl 254, id 8694, len 84, bad ip cksum 44f5! -> 45f5) (ttl 255, id 637, len 56) ^C 3 packets received by filter 0 packets dropped by kernel If we change the PF rule we created on obsd2 to "floating" and run the same test again, then the test case works exactly as expected: obsd1# ping -c 1 10.84.33.12 PING 10.84.33.12 (10.84.33.12): 56 data bytes 64 bytes from 10.84.33.12: icmp_seq=0 ttl=254 time=0.528 ms --- 10.84.33.12 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.528/0.528/0.528/0.000 ms obsd2# tcpdump -nvvpi vmx1 icmp tcpdump: listening on vmx1, link-type EN10MB 21:25:24.970742 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec seq:0) [icmp cksum ok] (ttl 255, id 27013, len 84) ^C 1 packets received by filter 0 packets dropped by kernel obsd2# tcpdump -nvvpi vmx2 icmp tcpdump: listening on vmx2, link-type EN10MB 21:25:24.971146 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec seq:0) [icmp cksum ok] (ttl 254, id 13581, len 84) ^C 3 packets received by filter 0 packets dropped by kernel obsd2# tcpdump -nvvpi vmx3 icmp tcpdump: listening on vmx3, link-type EN10MB 21:25:24.970800 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec seq:0) [icmp cksum ok] (ttl 254, id 27013, len 84) 21:25:24.970933 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec seq:0) [icmp cksum ok] (ttl 255, id 13581, len 84) ^C 2 packets received by filter 0 packets dropped by kernel I am interested in any feedback on the question of whether or not this is expected behavior... Thank you. Joe On Thu, May 10, 2018 at 1:50 AM Joe Crivello <josephcrive...@gmail.com> wrote: > Hello! > I have a trunk0 interface on a router (#1) that is used for a singular > purpose -- to pass (IPsec protected) traffic for an IPIP tunnel (gif0) to > another router (#2). I have configured PF rules on router #1 that prevent > any other type of traffic from passing on trunk0. There are several routing > table entries that forward to router #2 on gif0. > My objective is to configure an additional pass rule that would allow SSH > traffic destined for router #1 to pass in and out on trunk0. > The problem is that the aforementioned routes on gif0 cause packets sent in > reply to incoming SSH traffic to pass out on gif0
pf.conf "reply-to" routing parameter seemingly not working?
Hello! I have a trunk0 interface on a router (#1) that is used for a singular purpose -- to pass (IPsec protected) traffic for an IPIP tunnel (gif0) to another router (#2). I have configured PF rules on router #1 that prevent any other type of traffic from passing on trunk0. There are several routing table entries that forward to router #2 on gif0. My objective is to configure an additional pass rule that would allow SSH traffic destined for router #1 to pass in and out on trunk0. The problem is that the aforementioned routes on gif0 cause packets sent in reply to incoming SSH traffic to pass out on gif0 (after passing in on trunk0). This ends up getting blocked by PF on router #1 because the state-policy is set to if-bound (which is how I want it). I am trying to use reply-to to enforce symmetric routing, but it isn't working. As you will see below, my "reply-to" rule is matched, but the reply is _still_ routed to gif0: # tcpdump -nevvpi pflog0 tcp port 22 tcpdump: WARNING: snaplen raised from 116 to 224 tcpdump: listening on pflog0, link-type PFLOG 01:27:46.503040 rule 5/(match) [uid 0, pid 16018] pass in on trunk0: [uid 4294967295, pid 10] [SSH CLIENT IP].57427 > [TRUNK0 IP].22: S [tcp sum ok] 1707770457:1707770457(0) win 64240 (DF) (ttl 127, id 24244, len 52) 01:27:46.503069 rule 4/(match) [uid 0, pid 16018] block out on gif1: [uid 4294967295, pid 10] [TRUNK0 IP].22 > [SSH CLIENT IP].57427: S [tcp sum ok] 4100262020:4100262020(0) ack 1707770458 win 16384 (DF) (ttl 64, id 43497, len 52, bad ip cksum 0! -> d71b) ^C 2 packets received by filter 0 packets dropped by kernel # pfctl -sr | grep @5 @5 pass in log quick on trunk0 inet proto tcp from any to [TRUNK0 IP] port = 22 flags S/SA keep state (if-bound) reply-to @trunk0 Router #1 is running OpenBSD 6.2. Anyone have any idea why this isn't working the way I want it to? Joe
Re: Any typical pf.conf or sysctl settings to tweak/speedup NAT/networking stack throughput? (+ don't use USB dongles?)
On 2017/12/14 17:52, ti...@openmailbox.org wrote: > Hi Stuart, > > Thanks a lot for your response. I guess you made a point that for any > few-users usecase the default configuration is fine alrady really. If > relevant some followup question at bottom. > > > On 2017-12-14, ti...@openmailbox.org <ti...@openmailbox.org> wrote: > >> Hi! > >> > >> Do you see any typical pf.conf or sysctl settings to tweak/speedup > >> NAT/networking stack throughput? > >> > >> (On USB2 dongles, sigh. > >> > >> Current speed is quite OK actually, a client with good hardware would get > >> up to 70mbps through the NAT. I was still curious to know if there are any > >> obvious toggles in sysctl/pf.conf for up:ing NAT/networking stack > >> throughput though. RAM is not an issue with me, I have plenty. I thought > >> possibly some settings were set to unnecessarily low defaults, for OpenBSD > >> to work well on machines with <1GB RAM, say.) > >> > >> Tinker > > > > Generally not. The most common things to touch are: > > > > - raising net.inet.ip.ifq.maxlen if net.inet.ip.ifq.drops is > > increasing (trade-off against latency). > > My net.inet.ip.ifq.drops is 0 so I guess this one is not relevant to me. > > > - increasing "set limit states" on busier systems if needed. > > There's not users enough for the system to hit the 10,000 states default cap. > > > - using a wider port range than the default 50001:65535 on busier > > systems if needed (in PF nat rules; avoid starving the host itself > > of free ephemeral ports for locally initiated connections). > > This should be fine also, again not enough users. > > Indeed on USB3 NIC on USB2 port. > > > > 1. Could I set the NAT in some type of less secure / more promiscuous mode, > that would give multimedia applications such as video calling, more space to > act? PF only has binat (1:1 mapping between external and internal addresses, tries to maintain the same port numbers) and a type which is sometimes referred to as 'symmetric nat' - see diagrams on https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation > 2. I was thinking, is there any cap for the networking stack's use of buffer > space, that could constrian throughput, and that would be configurable? TCP buffer size limits only apply at the endpoints of the connection. Unless you're using relayd relays, that wouldn't be on the PF box. Other than that I think it would be mostly net.inet.ip.ifq.maxlen that would be involved. > 3. Could it be useful in any few-users scenario to up the "frags" pf limit > (and so the "kern.maxclusters" sysctl)? No idea, it's not something I usually touch. > 4. What are good commands to run to monitor NAT/networking stack throughput & > health? These are relatively easy to interpret "pfctl -si" "systat if" (bandwidth / packets-per-sec), though actually i normally use bwm-ng from packages for this Can help when tracking down problems, but harder to interpret / less immediately useful "systat mbuf" (stats relating to mbuf use per interface) "vmstat -m" (pool statistics, giving an idea of kernel memory use for things like PF state entries etc) But if you are running into this system being slow, I think the first thing anyone is going to suggest is to find a way to avoid the USB nic.
Re: Any typical pf.conf or sysctl settings to tweak/speedup NAT/networking stack throughput? (+ don't use USB dongles?)
Hi Stuart, Thanks a lot for your response. I guess you made a point that for any few-users usecase the default configuration is fine alrady really. If relevant some followup question at bottom. > On 2017-12-14, ti...@openmailbox.org <ti...@openmailbox.org> wrote: >> Hi! >> >> Do you see any typical pf.conf or sysctl settings to tweak/speedup >> NAT/networking stack throughput? >> >> (On USB2 dongles, sigh. >> >> Current speed is quite OK actually, a client with good hardware would get up >> to 70mbps through the NAT. I was still curious to know if there are any >> obvious toggles in sysctl/pf.conf for up:ing NAT/networking stack throughput >> though. RAM is not an issue with me, I have plenty. I thought possibly some >> settings were set to unnecessarily low defaults, for OpenBSD to work well on >> machines with <1GB RAM, say.) >> >> Tinker > > Generally not. The most common things to touch are: > > - raising net.inet.ip.ifq.maxlen if net.inet.ip.ifq.drops is > increasing (trade-off against latency). My net.inet.ip.ifq.drops is 0 so I guess this one is not relevant to me. > - increasing "set limit states" on busier systems if needed. There's not users enough for the system to hit the 10,000 states default cap. > - using a wider port range than the default 50001:65535 on busier > systems if needed (in PF nat rules; avoid starving the host itself > of free ephemeral ports for locally initiated connections). This should be fine also, again not enough users. Indeed on USB3 NIC on USB2 port. 1. Could I set the NAT in some type of less secure / more promiscuous mode, that would give multimedia applications such as video calling, more space to act? 2. I was thinking, is there any cap for the networking stack's use of buffer space, that could constrian throughput, and that would be configurable? 3. Could it be useful in any few-users scenario to up the "frags" pf limit (and so the "kern.maxclusters" sysctl)? 4. What are good commands to run to monitor NAT/networking stack throughput & health? Thanks! Tinker
Re: Any typical pf.conf or sysctl settings to tweak/speedup NAT/networking stack throughput? (+ don't use USB dongles?)
On 2017-12-14, ti...@openmailbox.org <ti...@openmailbox.org> wrote: > Hi! > > Do you see any typical pf.conf or sysctl settings to tweak/speedup > NAT/networking stack throughput? > > (On USB2 dongles, sigh. > > Current speed is quite OK actually, a client with good hardware would get up > to 70mbps through the NAT. I was still curious to know if there are any > obvious toggles in sysctl/pf.conf for up:ing NAT/networking stack throughput > though. RAM is not an issue with me, I have plenty. I thought possibly some > settings were set to unnecessarily low defaults, for OpenBSD to work well on > machines with <1GB RAM, say.) > > Tinker Generally not. The most common things to touch are: - raising net.inet.ip.ifq.maxlen if net.inet.ip.ifq.drops is increasing (trade-off against latency). - increasing "set limit states" on busier systems if needed. - using a wider port range than the default 50001:65535 on busier systems if needed (in PF nat rules; avoid starving the host itself of free ephemeral ports for locally initiated connections).
Re: Any typical pf.conf or sysctl settings to tweak/speedup NAT/networking stack throughput? (+ don't use USB dongles?)
Le 2017-12-14 05:30, ti...@openmailbox.org a écrit : Hi! Do you see any typical pf.conf or sysctl settings to tweak/speedup NAT/networking stack throughput? (On USB2 dongles, sigh. Current speed is quite OK actually, a client with good hardware would get up to 70mbps through the NAT. I was still curious to know if there are any obvious toggles in sysctl/pf.conf for up:ing NAT/networking stack throughput though. RAM is not an issue with me, I have plenty. I thought possibly some settings were set to unnecessarily low defaults, for OpenBSD to work well on machines with <1GB RAM, say.) Tinker Hello, What is the USB dongle here, a network adapter ? Maybe it's simply the dongle limiting the bandwidth. Regards
Any typical pf.conf or sysctl settings to tweak/speedup NAT/networking stack throughput? (+ don't use USB dongles?)
Hi! Do you see any typical pf.conf or sysctl settings to tweak/speedup NAT/networking stack throughput? (On USB2 dongles, sigh. Current speed is quite OK actually, a client with good hardware would get up to 70mbps through the NAT. I was still curious to know if there are any obvious toggles in sysctl/pf.conf for up:ing NAT/networking stack throughput though. RAM is not an issue with me, I have plenty. I thought possibly some settings were set to unnecessarily low defaults, for OpenBSD to work well on machines with <1GB RAM, say.) Tinker
Re: Problems with pf.conf I think, making a functioning router more reliable.
Hi,
With pfctl -vf I get this, se file attached. I have made three small
changes by now due to input from Mikael, see reciver.
1. I changed the second match, nat, rule to be from 192.168.137.0/24
instead of from !(egress:network). I also added a third match
rule to cover 192.169.138.0/24, that is DMZ.
2. I added (egress) instead of any in the last rule to narow down the
port forwarding to DMZ.
3. I added the antispoof line from the openBSD building
a router guide for all network adapters.
All these changes are included in the new printout from
pfctl -vf
Regards
Magnus
2017-10-21 19:15 GMT+02:00 edgar <ed...@pettijohn-web.com>:
> Try:
>
> # pfctl -vf /etc/pf.conf
>
> This will load the ruleset as well as print out what the rules translate to.
> It will also show errors if there are any.
>
> Post what the rules translate to. I think it will be easier to read.
>
>
> On Oct 21, 2017 at 8:19 AM, wrote:
>
> Hi,
> Thanks for answering and taking your time to my problem.
> A friend recommended me to ask the mailing list about my problem.
> I'm sorry if my question is too uninformed.
>
> After a little research I now
> know what you mean by dmesg, debug and systat. Here are my dmesg
> print out. I do not know how to debug the problem and I tried to print
> systat even if I do not know if that can help anyone to understand my
> problem. Systat looks like some sort of live printout function.
>
> The question regards just the rules in my pf.conf, are there an obvious
> misunderstandings there from my part to a more trained eye? Are for
> example the wrong adresses forbiden in the list och forbidden adresses
> in the beginning of the file or have I lost an inportant line of code?
>
> I tried to follow the guide on setting up a router from openBSD.org
> hompage. My openBSD version is 6.1.
>
> Regards
> Magnus Andrsson
>
> 2017-10-21 13:05 GMT+02:00 Karel Gardas :
>> Include also dmesg and try to debug this issue more with systat(1)
>> tool at least.
>>
>>>> Hi,
>>>> I think something must be wrong in my pf.conf file but I can't see
>>>> where.
>>>> I am using openBSD as a router with a LAN and a DMZ zone behind it.
>>>> What is wrong is not something sad and simple i think like a wrong
>>>> IP-address or something. The setup works in that i have internet i one
>>>> network and both internet and remote access in the DMZ zone. But the
>>>> setup is unreliable.
>
>
table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 192.168.0.0/16
198.18.0.0/15 198.51.100.0/24 203.0.113.0/24 }
set block-policy drop
set loginterface egress
set skip on { lo0 }
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from 192.168.137.0/24 to any nat-to (egress:0)
round-robin
match out on egress inet from 192.168.138.0/24 to any nat-to (egress:0)
round-robin
block drop in quick on ! egress inet from 83.253.232.0/21 to any
block drop in quick inet from 83.253.234.195 to any
block drop in quick on ! em1 inet from 192.168.137.0/24 to any
block drop in quick inet from 192.168.137.1 to any
block drop in quick on ! em2 inet from 192.168.138.0/24 to any
block drop in quick inet from 192.168.138.1 to any
block drop in quick on egress from to any
block return out quick on egress from any to
block drop all
pass out quick inet all flags S/SA
pass in on em1 inet all flags S/SA
pass in on em2 inet all flags S/SA
block drop in on em1 inet from any to 192.168.138.1
block drop in on em2 inet from any to 192.168.137.1
pass in on egress inet proto tcp from any to (egress) port = 443 flags S/SA
rdr-to 192.168.138.13 port 32400
Re: Problems with pf.conf I think, making a functioning router more reliable.
Try: # pfctl -vf /etc/pf.conf This will load the ruleset as well as print out what the rules translate to. It will also show errors if there are any. Post what the rules translate to. I think it will be easier to read. > > On Oct 21, 2017 at 8:19 AM,wrote: > > > Hi, Thanks for answering and taking your time to my problem. A friend > recommended me to ask the mailing list about my problem. I'm sorry if my > question is too uninformed. After a little research I now know what you mean > by dmesg, debug and systat. Here are my dmesg print out. I do not know how to > debug the problem and I tried to print systat even if I do not know if that > can help anyone to understand my problem. Systat looks like some sort of live > printout function. The question regards just the rules in my pf.conf, are > there an obvious misunderstandings there from my part to a more trained eye? > Are for example the wrong adresses forbiden in the list och forbidden > adresses in the beginning of the file or have I lost an inportant line of > code? I tried to follow the guide on setting up a router from openBSD.org > hompage. My openBSD version is 6.1. Regards Magnus Andrsson 2017-10-21 13:05 > GMT+02:00 Karel Gardas : > Include also dmesg and try to debug this issue > more with systat(1) > tool at least. > >>> Hi, >>> I think something must be wrong in my > pf.conf file but I can't see where. >>> I am using openBSD as a router with > a LAN and a DMZ zone behind it. >>> What is wrong is not something sad and > simple i think like a wrong >>> IP-address or something. The setup works in > that i have internet i one >>> network and both internet and remote access > in the DMZ zone. But the >>> setup is unreliable. >
Re: Problems with pf.conf I think, making a functioning router more reliable.
Hi, Thanks for answering and taking your time to my problem. A friend recommended me to ask the mailing list about my problem. I'm sorry if my question is too uninformed. After a little research I now know what you mean by dmesg, debug and systat. Here are my dmesg print out. I do not know how to debug the problem and I tried to print systat even if I do not know if that can help anyone to understand my problem. Systat looks like some sort of live printout function. The question regards just the rules in my pf.conf, are there an obvious misunderstandings there from my part to a more trained eye? Are for example the wrong adresses forbiden in the list och forbidden adresses in the beginning of the file or have I lost an inportant line of code? I tried to follow the guide on setting up a router from openBSD.org hompage. My openBSD version is 6.1. Regards Magnus Andrsson 2017-10-21 13:05 GMT+02:00 Karel Gardas <gard...@gmail.com>: > Include also dmesg and try to debug this issue more with systat(1) > tool at least. > >>> Hi, >>> I think something must be wrong in my pf.conf file but I can't see where. >>> I am using openBSD as a router with a LAN and a DMZ zone behind it. >>> What is wrong is not something sad and simple i think like a wrong >>> IP-address or something. The setup works in that i have internet i one >>> network and both internet and remote access in the DMZ zone. But the >>> setup is unreliable. dmesg Description: Binary data systat Description: Binary data pf.conf Description: Binary data
Re: Problems with pf.conf I think, making a functioning router more reliable.
Include also dmesg and try to debug this issue more with systat(1) tool at least. >> Hi, >> I think something must be wrong in my pf.conf file but I can't see where. >> I am using openBSD as a router with a LAN and a DMZ zone behind it. >> What is wrong is not something sad and simple i think like a wrong >> IP-address or something. The setup works in that i have internet i one >> network and both internet and remote access in the DMZ zone. But the >> setup is unreliable.
Re: Problems with pf.conf I think, making a functioning router more reliable.
In windows that file i sent you look ugly, her is another version
edited in notepad for easier reading. I add it in plain text below too.
Regarding the table of illegal addresses, I have no clue way they
are, I just followed a guide to the best of my ability.
#Table of illegal adresses forbiden below
table
{ 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
203.0.113.0/24 }
#General settings
set block-policy drop
set loginterface egress
set skip on lo0
#NAT settings
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
#General bloking rules
block in quick on egress from to any
block return out quick on egress from any to
block all
#Pass all out,
pass in on em1 and em2
pass out quick inet
pass in on em1 inet
pass in on em2 inet
#Isolate em1 and em2 from eachother, em2 is DMZ
block in on em1 to em2
block in on em2 to em1
#pass port 32400 in to DMZ for plex
pass in on egress proto tcp from any to any port 443 \
rdr-to 192.168.138.13 port 32400
2017-10-21 12:39 GMT+02:00 Magnus Andersson <magnus.k.anderss...@gmail.com>:
> Hi,
> I think something must be wrong in my pf.conf file but I can't see where.
> I am using openBSD as a router with a LAN and a DMZ zone behind it.
> What is wrong is not something sad and simple i think like a wrong
> IP-address or something. The setup works in that i have internet i one
> network and both internet and remote access in the DMZ zone. But the
> setup is unreliable.
>
> Sometimes it take a long time before the router answers, sometimes
> nothing gets through what so ever and then it works again. If it helps I
> can tell you I even needed to reboot the router ones because it seamed
> my openBSD installation managed to choke it self up. I can't believe it,
> not even my old Linux Debian router use to do that.
>
> My problem is not hardware related, I regularly go through the systems
> and my internet connection is optical and reliable. My cables are double
> insulated cat7 with routers from Cisco. I can not see how the problems
> can be in any of that.
>
> My problem starts when i change from Linux and Shorewall to openBSD
> and PF. I wanted to learn PF this last 4 years but have not had time
> before.
>
> I think it is just something I can't understand in my pf.conf, please read it
> throw and see if you can find any problems in it. My hope is you will find
> something. In Shorewall I just say what I want and the program makes
> the IP-table rules for me. I thing the problem here is that I am an
> incompetent in writing good solid PF-rules. Please help.
>
> Regards
> Magnus Andersson
> Sweden
pf.conf
Description: Binary data
Problems with pf.conf I think, making a functioning router more reliable.
Hi, I think something must be wrong in my pf.conf file but I can't see where. I am using openBSD as a router with a LAN and a DMZ zone behind it. What is wrong is not something sad and simple i think like a wrong IP-address or something. The setup works in that i have internet i one network and both internet and remote access in the DMZ zone. But the setup is unreliable. Sometimes it take a long time before the router answers, sometimes nothing gets through what so ever and then it works again. If it helps I can tell you I even needed to reboot the router ones because it seamed my openBSD installation managed to choke it self up. I can't believe it, not even my old Linux Debian router use to do that. My problem is not hardware related, I regularly go through the systems and my internet connection is optical and reliable. My cables are double insulated cat7 with routers from Cisco. I can not see how the problems can be in any of that. My problem starts when i change from Linux and Shorewall to openBSD and PF. I wanted to learn PF this last 4 years but have not had time before. I think it is just something I can't understand in my pf.conf, please read it throw and see if you can find any problems in it. My hope is you will find something. In Shorewall I just say what I want and the program makes the IP-table rules for me. I thing the problem here is that I am an incompetent in writing good solid PF-rules. Please help. Regards Magnus Andersson Sweden pf.conf Description: Binary data
Weard pf.conf isue wen opening port for remote access
For a friend who host a game server i create localy a SQL database for
fetching stats, so i created below rule
pass in quick on $ext_if proto { tcp,udp } from (ip adres here) to
$ext_if port 3306 rdr-to 192.168.0.228
after a pfctl the database returnd a sql error, that it was unable to
connect to it.
So i created a 2nd rule set (and did a # in front of the 1st rule)
pass in quick on $ext_if proto { tcp,udp } from any to $ext_if port 3306
rdr-to 192.168.0.228
And yes, a connection was made.
so, i revered the settings, i dont want unwanted hammering on my sql server.
all went well, no isues.
so i set up the 2nd pool connection.
and again, NO connection possible, and the 1st pool also died with it.
what am i doing wrong so remote connection are possible ?
any suggestions ?
Tony.
