Re: 2 gateways, route-to probs.
I tried: pass out on rl0 route-to ne1:123.123.123.7 from any to 123.123.123.123 keep state but it didn't work. Your assumption was correct, the default route is through rl0. Maybe with some more information that comes to mind. It's not possible to run a mailserver on the 234.234.234.234 ip address since port 25 is blocked on that network. I have however, always been running a mailserver on the 123.123.123.123 ip address (which was the interface with the default route before I got my second internet gateway). I would still like to do that, while all of my surfing goes out 234.234.234.234 since that is the ip adres with the biggest bandwidth. Problem now is that, from the outside, nobody can connect to 123.123.123.123 because replies get sent out through the default route, which is through rl0, with a different ip address. Does this help? Grts. Matijs - Original Message - From: "Daniel Hartmeier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 13, 2002 10:50 PM Subject: Re: 2 gateways, route-to probs. > On Tue, Aug 13, 2002 at 10:25:19PM +0200, Matijs wrote: > > > pass out on ne1 route-to ne1:123.123.123.7 from any to 123.123.123.123 keep > > state > > > > ... but this doesn't work. Pings to 123.123.123.123 get 'replied' to through > > the rl0 (234.234.234.234) interface. > > I assume your default route is through rl0. The problem is that the > above rule does only apply to packets that go out through ne1, which > the packets in question don't (due to the default route). > > Try > > pass out on rl0 route-to ne1:123.123.123.7 ... > > instead. > > Daniel
Re: 2 gateways, route-to probs.
On Tue, Aug 13, 2002 at 10:25:19PM +0200, Matijs wrote: > pass out on ne1 route-to ne1:123.123.123.7 from any to 123.123.123.123 keep > state > > ... but this doesn't work. Pings to 123.123.123.123 get 'replied' to through > the rl0 (234.234.234.234) interface. I assume your default route is through rl0. The problem is that the above rule does only apply to packets that go out through ne1, which the packets in question don't (due to the default route). Try pass out on rl0 route-to ne1:123.123.123.7 ... instead. Daniel
Re: 2 gateways, route-to probs.
Hello Daniel, Cool to get a reply from the great DH himself! I was hoping the sample I posted would suffice, however, this is as far as I got: == /etc/pf.conf = # ethernet: rl0 234.234.234.234 # cable: ne1 123.123.123.123 # lan: ne3 192.168.0.1 scrub in all scrub out all nat on rl0 from 192.168.0.0/23 to any -> 234.234.234.234 pass in all pass out all pass out on ne1 route-to ne1:123.123.123.7 from any to 123.123.123.123 keep state == .. but this doesn't work. Pings to 123.123.123.123 get 'replied' to through the rl0 (234.234.234.234) interface. I know, no firewall yet, but I would like to get things working first and then extend the ruleset. :) Greetings, Matijs - Original Message - From: "Daniel Hartmeier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 13, 2002 10:02 PM Subject: Re: 2 gateways, route-to probs. > On Tue, Aug 13, 2002 at 09:11:38PM +0200, Matijs wrote: > > > I am told I should use a route-to rule in /etc/pf.conf but I am totally > > lost. > > Post a minimal rule set that reproduces the problem. Someone might spot > the problem. If you expect someone to write the entire rule set for you, > you better get your paypal account loaded and ready. > > Daniel
Re: 2 gateways, route-to probs.
On Tue, Aug 13, 2002 at 09:11:38PM +0200, Matijs wrote: > I am told I should use a route-to rule in /etc/pf.conf but I am totally > lost. Post a minimal rule set that reproduces the problem. Someone might spot the problem. If you expect someone to write the entire rule set for you, you better get your paypal account loaded and ready. Daniel
2 gateways, route-to probs.
Hi there, I posted this on comp.unix.bsd.openbsd.misc as well but didn't get an answer soon enough. Some of you probably think I'm too impatient but I kind of need the answer to be able to receive mail. So here goes: I'm running an OpenBSD router with a snapshot from 10/8 and would like to use 2 gateways. 1 for nat and all internet traffic, and the other ONLY as a mailserver. I'll try to explain: rl0: ethernet 123.123.123.123, netmask 255.255.255.128, gateway 123.123.123.254 ne1: cable 234.234.234.234, netmask 255.255.252.0, gateway 234.234.234.7 ne3: lan 192.168.0.1 /etc/mygate: 123.123.123.254 what I would like is for my postfix mailserver to listen on ne1, however, ne1 (234.234.234.234) isn't even pingable from the internet whereas 123.123.123.123 is... nat is already in place on rl0 and working... I am told I should use a route-to rule in /etc/pf.conf but I am totally lost. Anyone out there who can help me? Gr. Blender
Re: Commenting rule sets
On Tue, Aug 13, 2002 at 10:28:38AM -0700, Paul B. Henson wrote:
> On Tue, 13 Aug 2002, Philipp Buehler wrote:
>
> > On 13/08/2002, francisco <[EMAIL PROTECTED]> wrote To Paul B. Henson:
> > > > foonets = "{ 10.0.0.0/24, # subnet blah
> > > > 10.0.1.0/24, # important stuff
> > > > 10.0.2.0/24 # don't forget
> > > > }"
> > >
> > > it does in -current, since July 19, 2002.
> >
> > And it does not since some hours later.
>
> Out of curiosity, what style of comment was temporarily supported,
exactly the one you used above.
> and why
> was it removed from the parser?
because it is bad language design.
well, I must admit I okay'd that myself... but string concat is a much
better solution.
msg00092/pgp0.pgp
Description: PGP signature
Re: Commenting rule sets
On Tue, 13 Aug 2002, Philipp Buehler wrote:
> On 13/08/2002, francisco <[EMAIL PROTECTED]> wrote To Paul B. Henson:
> > > foonets = "{ 10.0.0.0/24, # subnet blah
> > > 10.0.1.0/24, # important stuff
> > > 10.0.2.0/24 # don't forget
> > > }"
> >
> > it does in -current, since July 19, 2002.
>
> And it does not since some hours later.
Out of curiosity, what style of comment was temporarily supported, and why
was it removed from the parser?
I do think some way of documenting sets defined in a variable would be
useful.
--
Paul B. Henson | (909) 869-3781 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | [EMAIL PROTECTED]
California State Polytechnic University | Pomona CA 91768
Re: Newbie Question (one of many to come)
On Mon, Aug 12, 2002 at 03:27:35PM -0700, Chris Willis wrote: > I did not want to discuss the particular application, as it was developed > by an outside vendor for us to use. It is a confidential app. > > Besides, the application is not of consequence. It matters whether the protocol embeds client IP addresses inside the data stream. There are many such protocols that don't survive NAT at all. If you don't know or can't tell, try the procedure I suggested to find out. > The logistical problems don't seem that big of a deal. If the server > records that 192.168.100.100 sends out tcp 5000 packets to 20.20.20.20, > then it should have no problem knowing that udp 4900-1 should go back to > 192.168.100.100. Heck, it probably isn't even much extra code. In case of instant messaging clients and online games, there will be multiple concurrent connections, and the problem is forwarding the back-channels to the right local client. The firewall gets an incoming UDP packet to port 4900. It checks the state table and sees the following established TCP connections: 192.168.100.100:60001 -> $ext_if:55001 -> 20.20.20.20:5000 192.168.100.101:60001 -> $ext_if:55002 -> 20.20.20.20:5000 192.168.100.200:61234 -> $ext_if:55003 -> 20.20.20.20:5000 Where should the incoming UDP packet be forwarded to? .100, .101 or .200? If you're claiming general usefulness for a broad range of protocols, you have to address this case. Daniel
Re: Commenting rule sets
On 13/08/2002, francisco <[EMAIL PROTECTED]> wrote To Paul B. Henson:
> > foonets = "{ 10.0.0.0/24, # subnet blah
> > 10.0.1.0/24, # important stuff
> > 10.0.2.0/24 # don't forget
> > }"
>
> it does in -current, since July 19, 2002.
And it does not since some hours later.
Re: Commenting rule sets
On Mon, 12 Aug 2002, Paul B. Henson wrote:
>
> in putting together a rule set, I'm going to have a number of instances of
> variable definitions such as the following:
>
> foonets = "{ 10.0.0.0/24,
> 10.0.1.0/24,
> 10.0.2.0/24 }"
>
> I'd really like to be able to comment these in line, e.g.
>
> foonets = "{ 10.0.0.0/24, # subnet blah
> 10.0.1.0/24, # important stuff
> 10.0.2.0/24 # don't forget
> }"
>
>
> however, the parser does not currently support this. Is there any way to
> accomplish this type of commenting or achieve a similar documentation
> without using inline comments?
it does in -current, since July 19, 2002.
Check out http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/parse.y for
a complete list of changes, like string concatenation.
-f
http://www.blackant.net/
Commenting rule sets
in putting together a rule set, I'm going to have a number of instances of
variable definitions such as the following:
foonets = "{ 10.0.0.0/24,
10.0.1.0/24,
10.0.2.0/24 }"
I'd really like to be able to comment these in line, e.g.
foonets = "{ 10.0.0.0/24, # subnet blah
10.0.1.0/24, # important stuff
10.0.2.0/24 # don't forget
}"
however, the parser does not currently support this. Is there any way to
accomplish this type of commenting or achieve a similar documentation
without using inline comments?
If not, any thoughts on implementing some type of inline comment?
allowing the above syntax? Or perhaps C style?
foonets = "{ 10.0.0.0/24 /* subnet blah */,
10.0.1.0/24 /* important stuff */,
10.0.2.0/24 /* don't forget */
}"
I don't really want to have a comment before the variable definition, as
there will be anywhere from dozens to hundreds of subnets.
Thanks...
--
Paul B. Henson | (909) 869-3781 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | [EMAIL PROTECTED]
California State Polytechnic University | Pomona CA 91768
RE: Newbie Question (one of many to come)
>Well, the admins who would potentially use this proposed feature, yes. >It would not take a lot of effort to trick the firewall into exposing >the ports. People aren't perfectly capable of writing a good ruleset. >This is evident from the amount of traffic on the mailing lists asking >for assistance in creating rudimentary rule sets. I agree, most people seem to require assistance with basic rulesets. However, can someone offer an example of how the proposed feature could be exploited from the outside? Assuming there is no NAT... can't think of anything myself. Cheers, Adrian.
Re: Newbie Question (one of many to come)
On Mon, Aug 12, 2002 at 03:27:35PM -0700, Chris Willis wrote: > I did not want to discuss the particular application, as it was developed > by an outside vendor for us to use. It is a confidential app. It would have be nice if you had mentioned this initially. Perhaps the application itself could be modified. > Besides, the application is not of consequence. Actually it sort of is. Seeing as you're making suggestions to modify the behavior of a low level packet filter in order to ensure that the application performs correctly. > The logistical problems don't seem that big of a deal. If the server > records that 192.168.100.100 sends out tcp 5000 packets to 20.20.20.20, > then it should have no problem knowing that udp 4900-1 should go back to > 192.168.100.100. Heck, it probably isn't even much extra code. You might want to actually look at the code before making such statements. Or perhaps you can do it yourself since it isn't even much extra code. > putting words into my email that I never typed. Actually, the mod that I > proposed would be great with the majority of IM and P2P clients out > there, wouldn't it? No it wouldn't. What are you talking about? > And finally, you say that sysadmins would ruin rulesets? Why are you so > intent on treating people like children? You should operate on the > assumption that people are perfectly capable of writing a good ruleset. > When you operate on the assumption that people are incompetent, you just > come off as very arrogant. I certainly don't enjoy dealing with arrogant > people. Well, the admins who would potentially use this proposed feature, yes. It would not take a lot of effort to trick the firewall into exposing the ports. People aren't perfectly capable of writing a good ruleset. This is evident from the amount of traffic on the mailing lists asking for assistance in creating rudimentary rule sets.
Re: Newbie Question (one of many to come)
I did not want to discuss the particular application, as it was developed by an outside vendor for us to use. It is a confidential app. Besides, the application is not of consequence. The logistical problems don't seem that big of a deal. If the server records that 192.168.100.100 sends out tcp 5000 packets to 20.20.20.20, then it should have no problem knowing that udp 4900-1 should go back to 192.168.100.100. Heck, it probably isn't even much extra code. You can translate all you wish - that is not my fault that you are putting words into my email that I never typed. Actually, the mod that I proposed would be great with the majority of IM and P2P clients out there, wouldn't it? And finally, you say that sysadmins would ruin rulesets? Why are you so intent on treating people like children? You should operate on the assumption that people are perfectly capable of writing a good ruleset. When you operate on the assumption that people are incompetent, you just come off as very arrogant. I certainly don't enjoy dealing with arrogant people. -Original Message- From: Jolan Luff <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Mon, 12 Aug 2002 13:38:17 -0400 Subject: Re: Newbie Question (one of many to come) > On Mon, Aug 12, 2002 at 10:16:34AM -0700, Chris Willis wrote: > > I am puzzled still. No one can explain why it is bloated junk. It > would > > assist people who need to handle complex applications with their > firewall. > > Daniel gave a rather good explanation as to the logistical problems to > implement something such as this. He also pointed out why it is > somewhat pointless. Adding complexities such as this to pf for little > gain means bloat. Think of it as "cost benefit analysis". > > When you say "It would assist people..." I translate that as "me". > When you say "handle complex applications" I translate that as "create > a good method for system administrators to ruin rulesets". > > Of course, if you took the time to reply to Daniel's last e-mail on the > subject and explained in more detail what the particulars of this > application are, maybe people would be more receptive. > > - jolan
