Hi
I've been having a heck of a time getting this straight, and could use a hand.
Any help would be appreciated!
I have a hosted VPS that's connected to my home/ofc over a VPN.
The VPN endpoint boxes are the VPS and my home/ofc firewall.
Both boxes are running Shorewall.
And, I have a mail
Tom,
on my HOME/OFC FIREWALL
-
HOME/OFC FIREWALL + Shorewall firewall
eth0: D.D.D.2/29
eth1: 192.168.1.2/24
tun0: 172.20.0.2/24
loc: 127.0.0.1/8
-
/interfaces
#ZONE
Tom,
> > 192.168.1.50 is in the "int" zone, isn't it? shouldn't that be
> >
> > /rules
> > ...
> > ACCEPT vpn1 int:192.168.1.50tcp
> > 25,587
> > DNAT int:192.168.1.50 vpn1:172.20.0.1 tcp 25
> > ..
I'm defining my stoppedrules
I set up a simple one to only allow SSH/VPN access from my HomeIPs
/stoppedrules
#ACTION SOURCE DEST PROTO DEST
SOURCE
# PORT(S)
PORT(S)
I'm configuring Shorewall to manage a Comcast dynamic connection.
I'm following http://shorewall.net/MyNetwork.html
Setting up the lsm-script in /lib.private the instructions show
/lib.private
start_lsm() {
...
cat < /etc/lsm/shorewall.
I've setup my Shorewall to handle my VoIP -- access to/from an adapter on my
LAN, plus additional signalling.
These /rules
/action.VoIP
#ACTION SOURCE DESTPROTO DEST SOURCE
ORIGINAL
#
I'm still struggling with forwarding SMTP traffic across a VPN and into my LAN.
After a week+, I still can't get this working :-/
Monkeying aaround, I screwed up the VPN, too. That's been fixed for me, and
I'm restarting with a working VPN setup,
SERVER (shorewall)
eth
> If you can't explain why you need the loc zone, then get rid of it!!!
OK. it's gone. next?
> > DNAT net $FW:192.168.1.2tcp 25-
> > S.S.S.S
>
> Isn't 192.168.1.2 in the vpn1 zone Why do you specify $FW in the
> DEST column???
I entered this rule bec
Vernon,
On Thu, Jul 24, 2014, at 06:30 PM, Vernon Fort wrote:
> >> DNAT net vpn1:192.168.1.2tcp 25 S.S.S.S
>
> Curious - is the VPN on the same host as Shorewall. I ask because I've never
> had to use a DNAT with strongswan+Shorewall on the same server. I normally
> set the acce
> I'm simply trying to get you to think rather than "trying random things".
I appreciate the intent. The "trying random things" is what this has devolved
to; it's NOT for lack of trying to think about it. As I said I don't
understand this. The clearest evidence of that is that after a week or
On Fri, Jul 25, 2014, at 07:40 AM, Tom Eastep wrote:
> ...
Watching that example of stepping through the flow was quite useful; Something
to study.
> The configuration on the SERVER is now correct and the issue is on the CLIENT.
OK
> What is the shorewall.conf setting for ROUTE_FILTER on the
I'm working on following & understanding the flow of packets across all of
*this*.
when I exec telnet from an external host, I see at CLIENT
tcpdump -i tun1
11:32:16.532625 IP E.E.E.E.54277 > 192.168.1.2.smtp: Flags [S], seq
1312623728, win 32768, options [mss 1308,nop,wscale 3,sackOK,nop
> From the dump:
>
> /proc/sys/net/ipv4/conf/all/rp_filter = 1
verifying at CLIENT
cat /proc/sys/net/ipv4/conf/all/rp_filter
1
> So *something* is setting that. Is there an entry for it in
> /etc/sysctl.conf?
checking
grep rp_filter /etc/sysctl.conf
net.ipv4.conf.all.rp_f
at CLIENT checked
> /etc/shorewall/interfaces:
>
> vpn tun+optional,...
/interfaces
net EXT_IF
physical=eth0,tcpflags,nosmurfs,logmartians=1,sourceroute=0
lan INT_IFphysical=eth1,logmartians=1
vpn1 tun+ -
> /etc/shorewall/providers:
>
> You don't seem to have an ACCEPT rule for SMTP vpn1->lan.
added
ACCEPTvpn1lan:192.168.1.2tcp25,587
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines
> Leave the COPY column empty ("-")
noting from providers.annotated
# #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY
OPTIONSCOPY
# ISP1 1 1main eth0 206.124.146.254
track,balance eth2
# ISP
On Fri, Jul 25, 2014, at 01:52 PM, Tom Eastep wrote:
> If you can't get it sorted, please send another dump of the CLIENT; this
> time as a compressed attachment so I can load it into an editor.
I'll see if I can get anywhere, and if not, send the attachment.
I've verified that, at CLIENT, I'm st
> You will want to add 'optional' as an option for vpn1 -- otherwise,
> Shorewall won't start if the VPN is down.
I thought the optional was -- optional.
Added.
> I thought that the server was 192.168.1.2.
Yes. Typo. Fixed.
Still poking ...
--
Back to compile errors
/providers
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY
OPTIONS COPY
isp 1- maineth0detect
balance -
vpn 2- maintun1detect
with
/zones
fw firewall
net ipv4
lan ipv4
vpn1ipv4
/interfaces
?FORMAT 2
#ZONE INTERFACE OPTIONS
net EXT_IF
physical=eth0,tcpflags
sorry, that was a test on a friend's machine.
same test, on mine, yields the same errors & fixes
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free co
Still can't telnet thru :-/
at CLIENT, with
/zones
fwfirewall
net ipv4
lan ipv4
vpn1 ipv4
/interfaces
net EXT_IF
physical=eth0,tcpflags,nosmurfs,logmartians=1,sourc
> The 'vpn' provider is not starting; what output does 'shorewall-lite
> restart' produce?
at CLIENT
checking state of tun1
ip addr ls tun1
12: tun1: mtu 1500
qdisc pfifo_fast state UP group default qlen 100
link/none
inet 10.0.0
> Please change the vpn provider line to
>
> vpn2--tun1 10.0.0.1fallback-
changed
/providers
- vpn2--tun1detect fallback-
+ vpn2--tun110.0.0.1fallback-
recompiled
still
On Sat, Jul 26, 2014, at 06:42 AM, Tom Eastep wrote:
> sh -x /var/lib/shorewall-lite/firewall 2> trace
>
> The 'trace' file will contain a shell trace.
That returns
sh -x /var/lib/shorewall-lite/firewall 2> trace
Usage: /var/lib/shorewall-lite/firewall [ options ]
> This is way too late in the trace.
>
> Does 'shorewall-lite status -i' show tun1 as disabled? If so, type:
yes it does
> shorewall-lite enable tun1
> shorewall-lite restart
still fails as above
> If that doesn't work, you need to look much earlier in the trace for
> 'interface_i
I've been thinking through routing.
At
http://shorewall.net/MultiISP.html
it states
"You should disable all default route management outside of Shorewall. "
in the case of
USE_DEFAULT_RT=Yes
I've been trying to follow that document and amy still at the fuzzy stage.
I'm unclear as to w
Reading
http://shorewall.net/shorewall_extension_scripts.htm
I'm installing a number of convenience scripts in
/lib.private
It's clear how they're referenced/invoked in the various shorewall stages.
Is it possible to invoke a single script from the shorewall cmd line?
e.g., if
> Shorewall actually has features to set most of the important entries in
> /proc/sys/net.
My question's not about setting /proc/sys/net -- It was simply an example for
this post's actual question ...
Consider this instead
/lib.private
do_something() {
> You mean that you want to do something like 'shorewall run foo'?
Yes. To execute just a single/named function/routine defined in lib.private.
Is 'run', here, rhetorical? Don't see a run option to my currently-installed
shorewall(-lite)
> > Is 'run', here, rhetorical? Don't see a run option to my
> > currently-installed shorewall(-lite)
>
> Yes, it is. There is an (undocumented) 'call' command, but that doesn't
> allow calling functions in lib.private. lib.private is intended to be
> run out of the generated script rather than
> >>> shorewall-lite enable tun1
> >
> > What was the output of this command?
> >
>
> And after the command executes, what are the contents of
> /var/lib/shorewall-lite/status.tun1?
Sorry, I apparently forgot to hit 'send' on my reply :-/
> What was the output of this command?
shorewall-l
replacing
/interfaces
- vpn1 tun+ optional
+ vpn1 tun1 optional
seems to fix the 'tun1 is disabled' problem
that, plus additionally changing
/shorewall.conf
- USE_DEFAULT_RT=Yes
+ USE_DEFAULT_RT=
Inbound access seems to be behaving.
But, when 'vpn' provider is enabled, this resulting rule
> Table vpn:
> ...
> default via 10.0.0.1 dev tun1 src 10.0.0.2
ends up capturing all outbound, port-25 traffic from anywhere on my LAN and
pushing it out tun1.
since my question was
>> is that done with the ... rule you'd suggested?
I'll assume that
> Then change that rule to only apply to a single IP
means "yes", that /mangle is the right place to change this ^^ behavior.
Thanks!
Fyi, attempting to follow the docs, reading @
> > Is that true -- "/mangle" is supposed to replace "/rules" ? or was
> > "/tcrules" intended?
Back to rude, I see. If you'd rather not provide help, don't.
I _thought_ you might, in fact, have documentation that's written as intended.
And, I _thought_ it prudent to politely ask, rather than
36 matches
Mail list logo
