Yes, thats right!!
And it works!!! the only thing that I was missing is to copy tun0 interface
in providers.
Now, this work fine in my lab, but in production I have another Shorewall
(older) 3.4.2 and i have made the same, but with non luck ;(
look, when I try from my client to my dmz in the log appear
kernel: Shorewall:nic2dmz:ACCEPT:IN=tun0 OUT=eth0 SRC=10.8.0.13 DST=
192.168.0.15 LEN
(note that nic(nico) is openvpn zone)
There is no problem between internal zones, BUT if I try to go to my server
74.53.205.xxx
log this:_
kernel: Shorewall:all2all:REJECT:IN=tun0 OUT=eth2 SRC=10.8.0.13 DST=
74.54.56.xxx
It sounds like there ir no policy that apply, but in my policie file I have
nic net ACCEPT info
nic fw ACCEPT info
nic loc ACCEPT info
nic dmz ACCEPT info
ZONES:
fw firewall
cue ipv4
adm ipv4
dmz ipv4
p2p ipv4
vpn ipv4
loc ipv4
net ipv4
nic ipv4
Interfaces:
nic tun0 -
- eth0 detect proxyarp
net eth1 detect norfc1918
net eth2 detect norfc1918
Providers
ded 1 1 main eth1 $ETH1_GW
track,balance eth0,tun0
ngt 2 2 main eth2 $ETH2_GW
track,balance eth0,tun0
RULES:
ACCEPT nic net tcp ssh,http
ACCEPT nic loc all
Any Idea?
On 10/9/07, Tom Eastep <[EMAIL PROTECTED]> wrote:
>
> Jerry Vonau wrote:
>
> >
> > The openvpn tunnel, based on the masq entries, appears to be to
> > 201.221.xx.xx or 200.40.xx.xx *on the firewall*, that is supported by
> > the tunnels file entry.
> >
> > Based on the masq entries "eth1 10.8.0.0/24 201.221.xx.xx" it appears
> > that Nico wants to have the traffic from the vpn client to 74.53.205.xxx
> > appear to come from the fw/vpn-server's 201.221.xx.xx.
> > address, that would explain the push route in openvpn.
> >
> > I think this is what Nico wants:
> >
> > from the vpn-client to 74.53.205.xxx:
> > vpn-client (with host route) -> tunnel -> fw/vpn-server ->
> > masq to 201.221.xx.xx -> eth1gw -> 74.53.205.xxx
> >
> > from 74.53.205.xxx to the vpn-client:
> > 74.53.205.xxx -> eth1gw -> fw/vpn-server -> de-masq ->
> > tunnel -> vpn-client
> >
> > Nico:
> >
> > Could you clarify this for us please.
> >
>
> If that is indeed the case then your tip about the route_rules example in
> the Multi-ISP doc should solve the problem. The cause of the failure is
> that
> return traffic from 74.53.205.xxx is mis-routed.
>
> -Tom
> --
> Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
> Shoreline, \ http://shorewall.net
> Washington USA \ [EMAIL PROTECTED]
> PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
