Jerahmy Pocott skrev:
The Sonic Wall client doesn't trigger ANY firewall rules, which is why I
thought
there must be something going wrong with the NAT. It actually
establishes the
tunnel okay but never gets an IP address, from my understanding this client
uses some sort of dhcp over ipsec to provision the client address..
What I am getting using the standard PPTP method are a bunch of hits:
fxp1 @0:25 b x.x.x.x -> 10.0.0.3 PR gre len 20 (93) IN NAT
(rule @0:25 is the final 'block all' rule)
What is protocol 'gre'? Why is a NAT'd packet getting blocked?!
Thanks!
J.
On 25/11/2007, at 9:09 AM, Roger Olofsson wrote:
Hello again Jerahmy,
I would suggest that you verify what port(s) and protocol(s) 'Sonic
Wall Global VPN Client' needs to work.
I would also suggest that you look in the logfile from ipf to see what
it's blocking and when.
My guess is that the VPN client is using a protocol like IPSEC (IP
protocol 50) and possibly port 500 (IKE) for which you will have to
activate the ipnat proxy.
map WAN internal_ip/24 -> 0.0.0.0/32 proxy port 500 ipsec/udp
You might also try to disable the blocking of fragged packets. For
some VPN clients this can cause problems.
Good luck!
/Roger
Jerahmy Pocott skrev:
Sorry let me clarify..
There are two issues, one is connecting to any external VPN, with no
filter I
can establish a connection to PPTP VPN, but the 'Sonic Wall Global
VPN Client'
still fails to connect even with no filter rules.
The redirect for the CVS server has an ipf rule to allow traffic on
that port, but
users are getting connection refused messages.
I will include my ipf rules, I clearly need some sort of rule to
allow inbound for
the VPN to work, though I think the ipnat is breaking the Sonic Wall
client. Which
is strange because everything worked fine with ipfw/natd.
Here are my ipf rules:
# Allow all in/out on internel interface
pass in quick on fxp0 all
pass out quick on fxp0 all
# Allow all in/out on loopback interface
pass in quick on lo0 all
pass out quick on lo0 all
# Allow all out-going on public interface and keep state
pass out quick on fxp1 proto tcp from any to any flags S keep state
pass out quick on fxp1 proto udp from any to any keep state
pass out quick on fxp1 proto icmp from any to any keep state
# Block all inbound traffic from non-routable or reserved address spaces
block in quick on fxp1 from 192.168.0.0/16 to any #RFC 1918
private IP
block in quick on fxp1 from 172.16.0.0/12 to any #RFC 1918
private IP
block in quick on fxp1 from 10.0.0.0/8 to any #RFC 1918
private IP
block in quick on fxp1 from 127.0.0.0/8 to any #loopback
block in quick on fxp1 from 0.0.0.0/8 to any #loopback
block in quick on fxp1 from 169.254.0.0/16 to any #DHCP auto-config
block in quick on fxp1 from 192.0.2.0/24 to any #reserved for docs
block in quick on fxp1 from 204.152.64.0/23 to any #Sun cluster
interconnect
block in quick on fxp1 from 224.0.0.0/3 to any #Class D & E
multicast
# Block frags
block in quick on fxp1 all with frags
# Block short tcp packets
block in quick on fxp1 proto tcp all with short
# block source routed packets
block in quick on fxp1 all with opt lsrr
block in quick on fxp1 all with opt ssrr
# Block anything with special options
block in quick on fxp1 all with ipopts
# Block public pings
block in quick on fxp1 proto icmp all icmp-type 8
# Block ident
block in quick on fxp1 proto tcp from any to any port = 113
# Block all Netbios service. 137=name, 138=datagram, 139=session
# Block MS/Windows hosts2 name server requests 81
block in quick on fxp1 proto tcp/udp from any to any port = 137
block in quick on fxp1 proto tcp/udp from any to any port = 138
block in quick on fxp1 proto tcp/udp from any to any port = 139
block in quick on fxp1 proto tcp/udp from any to any port = 81
# Allow CVS access
pass in quick on fxp1 proto tcp/udp from any to any port = 2401
# Logged Blocking Rules #
# Block nmap OS fingerprint attempts
block in log first quick on fxp1 proto tcp from any to any flags FUP
# Block all other in coming traffic
block in log first quick on fxp1 all
Thanks for the help!
J.
On 25/11/2007, at 12:50 AM, Roger Olofsson wrote:
Hello Jerahmy,
Assuming you want to connect from the outside to your VPN.
Have you made sure that port 2401 is open for inbound traffic in
your ipf.rules?
You might also want to do 'ipnat -C -f <path to ipnat.rules>'. Man
ipnat ;^)
Greeting from Sweden
/Roger
Jerahmy Pocott skrev:
Hello,
I recently decided to give ipf and ipnat a try, previously I had
always been using
ipfw and natd. Since switching over I can no longer establish a VPN
tunnel from
any system behind the gateway.
I did 'ipf -F a' to flush all rules but I was still unable to
connect so I think it's a problem
with ipnat? Also my redirect from ipnat doesn't seem to work either.
These are the only ipnat rules I have:
(fxp1 is the external interface)
# ipnat built in ftp proxy rules
map fxp1 10.0.0.0/24 -> 0/32 proxy port 21 ftp/tcp
map fxp1 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp
# CVS Server on Fileserv
rdr fxp1 0/32 port 2401 -> 10.0.0.2 port 2401 tcp/udp
# nat all out going traffic on fxp1 from internal lan
map fxp1 10.0.0.0/24 -> 0/32
I can post my firewall rules too if that would help, however with
NO rules set it
still didn't work so I don't think that would help.. (I'm using the
klm which is default
to accept?)
Thanks!
J.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
Hello Jerahmy, (sorry for top-posting, btw).
Gre is protocol 47. In your firewall rules you only allow/block
protocols tcp/udp/icmp. If you want to use PPTP you will need to allow
both the port and the protocol for it.
Did you find out what ports and what protocols the VPN client needs? In
my earlier post I guessed that you would have to enable the IPSEC proxy
and allow protocol 50 and port 500. I gave an example on how to enable
the IPSEC proxy in ipnat.conf, ie:
map WAN 10.0.0.0/24 -> 0.0.0.0/32 proxy port 500 ipsec/udp
You could also try to do like this (early in the ipf.conf file),
depending on if you trust the vpn server or not:
pass out quick on WAN proto tcp/udp from <ip of vpn client> to <ip of
vpn server>
pass in quick on WAN from <ip of vpn server> to <ip of vpn client>
In your original question you mentioned having problems with CVS. From
the looks of it, you redirect CVS to 10.0.0.2, meaning that all users on
that machine can use CVS.
If you mean that users are on other machines, ie, not on 10.0.0.2 they
won't be able to use CVS. The solution to this would be to remove your
rdr to 10.0.0.2. My own rules for stateful filtering looks like this, I
am only allowing ports above 1023 for stateful:
# [ Enable stateful connections LAN->WAN for all ports > 1023 tcp/udp ]
pass out quick on WAN proto tcp from any to any port > 1023 flags S keep
state keep frags
pass out quick on WAN proto udp from any to any port > 1023 keep state
keep frags
BTW, to make changes to ipf/ipnat I use the following commands:
ipf -Fa -f <path_to_changed_ipf_file>
ipnat -C -f <path_to_changed_ipnat_file>
Good luck!
/Roger
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
