|
|||
PF supports interface group names jggimi, "lo" is valid and is used in FAQ examples.
But you are right, the skip rule makes it redundant. |
|
|||
jggimi has gone the extra mile by testing your ruleset, he has found no obvious problems.
It would seem the issue is elsewhere, one probable cause is that your ISP is filtering packets themselves... perhaps they're blocking incoming traffic on port 80. Please try using a different port to confirm if this is the case. |
|
|||
Hmm strange.
Quote:
Quote:
hostname.re0 contains inet 192.168.0.1 hostname.ral0 contains inet 192.168.1.1 Router is OpenBSD Workstation is ubuntu as well, there is no hostname.* Quote:
|
|
|||
BTW thanks for being so helpfull
|
|
||||
#1:
------- Please post the output of $ route -n show -inetYou may redact any private information, such as your Internet IP address. I ask for your routing information, because you just stated that you have a mygate(1) file, containing incorrect information ("192.168.1.1"). Your default route should be assigned by your ISP. If your ISP connection uses DHCP, the default route will be added when you connect. If your ISP connection is static, your ISP should have provided this information. /etc/mygate is used for static ip address configurations, and describes the default route. Perhaps, if you are using DHCP, a default route is already correctly added, then the use of an incorrect /etc/mygate just causes an error when /etc/netstart issues the route add for it. (That error should appear in /var/log/messages with each boot; you may want to look for it.) ------- #2 ------- Run tcpdump against your internal wired network, to see if the incoming Sync packet from the Internet makes it onto the local LAN. Perhaps the source of your problem is the server at 192.168.0.10. If you see packets get sent to the server, but no valid responses, you have a server problem. If you see valid two-way traffic back and forth, then run tcpdump against your external network. On the external network, if you only see the incoming packet, but no outbound responses, you have a routing problem. e.g.: # tcpdump -neti re0 host 192.168.0.10 # tcpdump -neti em0 host <your remote workstation> Last edited by jggimi; 11th July 2009 at 01:25 PM. |
|
||||
To be clear, regarding IP routing:
|
|
||||
Change your /etc/pf.conf per the BLUE and RED config fragments. Be careful about OBSERVING the very subtle changes (e.g. no "pass" in the rdr) and differences in keyword spellings (e.g. tag and tagged)
restart pf... Code:
pfctl -F all -vvf pf.conf Code:
tcpdump -eni pflog0 Code:
ext_if="em0" int_if="re0" wifi_if="ral0" local_net="{192.168.0.1/24, 192.168.1.1/24}" server="{ 192.168.0.10/32 }" icmp_types="echoreq" tcp_flags="flags S/SA keep state" table <abusers> persist set require-order no set skip on lo scrub in all nat on $ext_if from !($ext_if) -> ($ext_if:0) # ---- start group ----- rdr on $ext_if inet proto { tcp udp } \ from any to ($ext_if:0) port 80 tag MyWWW -> $server port 80 # pass in log quick on $ext_if inet proto {tcp udp} \ tagged MyWWW flags S/SA modulate state # pass out log quick on $int_if inet proto {tcp udp} \ tagged MyWWW keep state # ----- end group ----- block drop log all block in log quick from <abusers> pass out log on $ext_if proto tcp from any to any flags S/SA pass out log on $ext_if proto { udp,icmp } from any to any pass in log quick inet proto icmp all icmp-type $icmp_types pass in log quick on $wifi_if proto tcp to ($wifi_if) port ssh $tcp_flags (max-src-conn 8, max-src-conn-rate 15/5, overload <abusers> flush global) pass quick on { lo, $int_if, $wifi_if } # I don't write rules this way. # antispoof quick for { lo, $int_if, $ext_if, $wifi_if } # comment out for test purposes
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. Last edited by s2scott; 12th July 2009 at 09:55 AM. |
|
|||
yeh your sample didnt work, i put www on firewall and didnt have to worry about rdr rule. Working great now
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
back-sql - SQLConnect() failed | vol_o3 | OpenBSD General | 0 | 9th September 2009 09:36 AM |
pfstat fopen failed: ? | Calderon | FreeBSD General | 3 | 7th May 2009 08:52 AM |
phpPgAdmin login failed | gosha | General software and network | 14 | 17th March 2009 11:49 PM |
Communication with su failed | amandus | OpenBSD Packages and Ports | 7 | 17th July 2008 07:17 AM |
Failed Installs | dctr | OpenBSD Installation and Upgrading | 23 | 4th June 2008 04:25 AM |