VPN (interface) access for and all traffic through from single user -- how to do it?

VPN (interface) access for and all traffic through from single user -- how to do it?

[Jan Klod]

Hello!

There is one thing really troubling me for fourth day and I hope, this is the 
right place to ask for advices: 
I have VPN access through LAN NIC, I managed to log in the VPN server and, 
using ping -I ppp0 some.host.domain got an answer. Nothing more this far, but 
the initial goal was simply to grant an user access to VPN as toppic subject 
describes. Just like I would have started firefox -I ppp0!
(all user's traffic through ppp0, while other users can still go through 
eth1!)

Also this created an extra question: how web browser "knows", which interface 
should be used, if there are multiple?

I would greatly appreciate your help here, since my efforts following 
http://gentoo-wiki.com/HOWTO_PPTP_VPN_client_(Microsoft-compatible_with_mppe)
http://www.wlug.org.nz/SourceBasedRouting
http://lartc.org/lartc.pdf
just didn't succeed somehow. 

Hope, you know,
Jan

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Grant Taylor]

On 08/15/08 04:55, Jan Klod wrote:
> There is one thing really troubling me for fourth day and I hope, 
> this is the right place to ask for advices: I have VPN access through 
> LAN NIC, I managed to log in the VPN server and, using ping -I ppp0 
> some.host.domain got an answer. Nothing more this far, but the 
> initial goal was simply to grant an user access to VPN as toppic 
> subject describes. Just like I would have started firefox -I ppp0!
> 
> (all user's traffic through ppp0, while other users can still go 
> through eth1!)
> 
> Also this created an extra question: how web browser "knows", which 
> interface should be used, if there are multiple?

(With out having even looked at the links you provided I'm going to take 
a stab in the dark.)

I believe you are wanting to have your traffic go through the VPN as a 
default rather than through your existing default gateway.  (Presuming 
that this is the case.)

Add a route to the IP address of your remote VPN end point via your 
current default gateway.  (Bring the VPN up if it is not already up.) 
Add a new default gateway of the *inside* remote end of the VPN.  Remove 
your existing local default gateway.  Or if you would like you can 
change the metric of your existing local default gateway so that it is 
higher (thus less preferred) than the default gateway on the other end 
of the VPN.

Doing this will allow anything on the VPN client computer to route its 
traffic through the VPN with out having to modify any thing specific to 
each program.



Grant. . . .

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Jan Klod]

May I ask some commands?
Say, I have eth1 with address 192.168.2.34, router (and nameserver) address 
192.168.2.1 and I've connected to VPN through ppp0 with local  IP address 
215.155.114.16 and remote IP address 215.155.115.254! (VPN's gateway is 
194.12.33.1 for connecting) (VPN or PPTP)

At least, what are those command line entries, so I can browse network through 
VPN?
Hope, I explained better...

On Friday 15 August 2008 18:29:49 you wrote:
> > (all user's traffic through ppp0, while other users can still go
> > through eth1!)
> >
> > Also this created an extra question: how web browser "knows", which
> > interface should be used, if there are multiple?
>
> (With out having even looked at the links you provided I'm going to take
> a stab in the dark.)
>
> I believe you are wanting to have your traffic go through the VPN as a
> default rather than through your existing default gateway.  (Presuming
> that this is the case.)
Not really. My intend was, that linux user myuser1 is using VPN, but all 
others use LAN directly. So all users have network access, but only myuser1 
is connected through VPN!

Jan

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Jan Klod]

I forgot to mention: this is all done on and for single machine.
Interface "separation" could be done by packet marking.... 

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Grant Taylor]

On 08/15/08 11:14, Jan Klod wrote:
> May I ask some commands?

*nod*

> Say, I have eth1 with address 192.168.2.34, router (and nameserver) 
> address 192.168.2.1 and I've connected to VPN through ppp0 with local 
> IP address 215.155.114.16 and remote IP address 215.155.115.254! 
> (VPN's gateway is 194.12.33.1 for connecting) (VPN or PPTP)

So your client is 192.168.2.34 and your (current) default gateway is 
192.168.2.1.  You have a VPN established from your client to 
215.155.115.254.  Your end of the inside of the VPN is 
194.12.33.<something> and the remote end of the inside of the VPN is 
194.12.33.1.  Is all of this correct?  (I'm going to presume yes with 
the commands below.)

route add -host 215.155.114.254 gw 192.168.2.1
route add default gw 194.12.33.1 metric 1
route del default gw 192.168.2.1
route add default gw 192.168.2.1 metric 2

This should do the following:
  - Add a route to your VPN target by way of (the IP of) your (current) 
default gateway.
  - Add a the remote end of the inside of the VPN as your new default 
gateway with a low metric.
  - Delete your old (local) default gateway.
  - Re-add your old (local) default gateway with a higher metric.

> At least, what are those command line entries, so I can browse 
> network through VPN?

If by "browse" you mean browse the web or use any other ""standard 
internet service, you should be good to go.  If by "browse" you mean 
"Browse 'My Network Places'" you may run in to other SMB / CIFS related 
networking issues (crossing subnets).

> Hope, I explained better...

I think so.  Does my response help?



Grant. . . .

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Jan Klod]

Still asking questions. I tried to follow probably the most simple case 
presented here:
http://pptpclient.sourceforge.net/routing.phtml#all-to-tunnel
but result is no access to internet at all. How can I debug these things and 
find out what is going on? Now it is like in the dark...

Is it considerable to be a proof, that pptp VPN tunnel is working, if I can 
ping -i ppp0 <remote VPN address>?

Looking for solutions,
Jan

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Michael Alaimo]

Hi Jan,

I would use tcpdump and traceroute to aid in debugging.  nmap might also 
be useful.
I also forget exactly what to do here, so if someone else knows please 
help out.
If i recall correctly, there is a way you can direct traffic to your vpn 
using SNAT.
so like if iptables -t nat -A POSTROUTING -d vpn_endpoint -J SNAT 
--to-source local_vpn_endpoint

I think thats correct.  The idea here is to have only traffic to the vpn 
use the vpn, no?   Trafic would leave
your vpn endpoint, reach the other side.  The other side would reply 
back to your SNAT -to-source which
would get routed to your pc. 

I know this works with the *swan implementations, so using some sort of 
NAT may help.
I would use those tools to debug, but there are probably some others 
that would help as well.

Have you ever tried OpenVPN?  It have used it in an office situation 
before, and people appreciated it.

Please correct me if I am wrong.  Hope this helps.

Mike

Jan Klod wrote:
> Still asking questions. I tried to follow probably the most simple case 
> presented here:
> http://pptpclient.sourceforge.net/routing.phtml#all-to-tunnel
> but result is no access to internet at all. How can I debug these things and 
> find out what is going on? Now it is like in the dark...
>
> Is it considerable to be a proof, that pptp VPN tunnel is working, if I can 
> ping -i ppp0 <remote VPN address>?
>
> Looking for solutions,
> Jan
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Grant Taylor]

On 8/16/2008 3:47 PM, Jan Klod wrote:
> Is it considerable to be a proof, that pptp VPN tunnel is working, if 
> I can ping -i ppp0 <remote VPN address>?

If the address is on the inside of the VPN or on the LAN on the other 
end of the VPN, most likely.

> Looking for solutions,

Please reset everything to the way it was before trying things suggested 
(restart your network or reboot should do it).

Please provide the output of "ifconfig" and "route -n" after bring up 
the VPN and being able to ping like above.  I'll then try to provide 
example commands at that point to do what you are wanting.



Grant. . . .

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Grant Taylor]

On 8/16/2008 11:30 PM, Michael Alaimo wrote:
> I would use tcpdump and traceroute to aid in debugging.  nmap might also 
> be useful.

I agree that those are wonderful tools and quite often very handy. 
However I don't think things are to that point yet.  I believe that the 
OP is able to get the VPN up and functional with the remainder of the 
internet traffic going out his / her default internet connection, not 
the VPN.  Presuming that this is the case, this is just an issue of 
getting the routing set up correctly.

> I also forget exactly what to do here, so if someone else knows please 
> help out.
> If i recall correctly, there is a way you can direct traffic to your vpn 
> using SNAT.

If by "... direct traffic to your vpn ..." means cause replies to your 
traffic to come back towards you through the VPN, yes I agree.  You are 
wanting any traffic you send out through the VPN to appear as if it is 
coming from your VPN IP so that the traffic will be routed back to you 
through the VPN.  This is where SNAT / MASQUERADE comes in to play.

> so like if iptables -t nat -A POSTROUTING -d vpn_endpoint -J SNAT 
> --to-source local_vpn_endpoint

I think you are close.  However I would not match traffic that is 
destined to the VPN endpoint.  I say this because it is very unlikely 
that there will be much IP traffic that is actually destined to the 
other VPN end point its self.  Sure a lot of traffic will flow through 
it, but not be to it directly.

I think you are wanting to remove the "-d vpn_endpoint" from that line 
and possibly put "-o vpn_interface" in its place.  Seeing as how this is 
a dynamic connection (one that comes up and goes down at least compared 
to a static IP on a LAN connection) you could use the MASQUERADE target 
as a short cut as well as not maintaining connection state across 
interface flaps.

> I think thats correct.  The idea here is to have only traffic to the vpn 
> use the vpn, no?   Trafic would leave
> your vpn endpoint, reach the other side.  The other side would reply 
> back to your SNAT -to-source which
> would get routed to your pc.
> I know this works with the *swan implementations, so using some sort of 
> NAT may help.
> I would use those tools to debug, but there are probably some others 
> that would help as well.

*nod*  Source NAT is very likely going to be required to get his / her 
reply traffic back to his end of the VPN.  At least it will be required 
for any systems behind the computer connecting to the VPN.  If there are 
no computers behind it, then NAT should not be needed as the system's 
routing stack *should* choose the VPN IP any way.

> Have you ever tried OpenVPN?  It have used it in an office situation 
> before, and people appreciated it.

Just guessing, but based on the fact that the OP was referring to PPTP 
as well as Microsoft I'm betting that he / she is connecting to a 
Microsoft VPN server, which to the best of my knowledge does not use SSL 
VPNs, thus I don't think OpenVPN will be of much help in this case. 
That is not to say that OpenVPN is good or bad, just that it likely will 
not work in this situation (presuming the Microsoft VPN server).



Grant. . . .

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Jan Klod]

On Sunday 17 August 2008 07:31:33 you wrote:
> On 8/16/2008 3:47 PM, Jan Klod wrote:
> > Is it considerable to be a proof, that pptp VPN tunnel is working, if
> > I can ping -i ppp0 <remote VPN address>?
>
> If the address is on the inside of the VPN or on the LAN on the other
> end of the VPN, most likely.
I think so, but how to check?

>
> > Looking for solutions,
>
> Please reset everything to the way it was before trying things suggested
> (restart your network or reboot should do it).
>
> Please provide the output of "ifconfig" and "route -n" after bring up
> the VPN and being able to ping like above.  I'll then try to provide
> example commands at that point to do what you are wanting.

Here I go:

local ~ # dhcpcd -k eth1
local ~ # ifconfig eth1 down
local ~ # ifconfig eth1 up
local ~ # dhcpcd eth1
local ~ # ip route list
192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.111
127.0.0.0/8 dev lo  scope link
default via 192.168.2.1 dev eth1
local ~ # ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default


local ~ # pon mySERVERname debug dump logfd 2 nodetach
pppd options in effect:
debug           # (from command line)
nodetach                # (from command line)
logfd 2         # (from command line)
dump            # (from command line)
noauth          # (from /etc/ppp/options.mySERVERname )
name myLOGIN            # (from /etc/ppp/peers/mySERVERname )
remotename mySERVERname                 # (from /etc/ppp/peers/mySERVERname )
                # (from /etc/ppp/options.mySERVERname )
pty pptp 193.13.128.6 --nolaunchpppd            # 
(from /etc/ppp/peers/mySERVERname )
mru 1000                # (from /etc/ppp/options.mySERVERname )
mtu 1000                # (from /etc/ppp/options.mySERVERname )
lcp-echo-failure 10             # (from /etc/ppp/options.mySERVERname )
lcp-echo-interval 10            # (from /etc/ppp/options.mySERVERname )
ipparam mySERVERname            # (from /etc/ppp/peers/mySERVERname )
nobsdcomp               # (from /etc/ppp/options.mySERVERname )
nodeflate               # (from /etc/ppp/options.mySERVERname )
require-mppe-128                # (from /etc/ppp/options.mySERVERname )
using channel 29
Using interface ppp0
Connect: ppp0 <--> /dev/pts/7
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x76d7cdc3> <pcomp> 
<accomp>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xf4a5af8b> 
<pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xf4a5af8b> 
<pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x76d7cdc3> <pcomp> 
<accomp>]
sent [LCP EchoReq id=0x0 magic=0x76d7cdc3]
rcvd [CHAP Challenge id=0xad <be119e70047db182c48380880a0fbf66>, name 
= "vpn-gw"]
sent [CHAP Response id=0xad 
<8dce041691feeec08f9cc100cb4d12e3000000000000000084a80f09fe0a2aedd545eb7563057de7944cdef00012c5d900>, 
name = "myLOGIN"]
rcvd [LCP EchoRep id=0x0 magic=0xf4a5af8b]
rcvd [CHAP Success id=0xad "S=D35E31DAAB3F9837AA1159ACCC91DA05007EC37B"]
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 215.155.115.254>]
sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 215.155.115.254>]
rcvd [IPCP ConfNak id=0x1 <addr 215.155.114.15>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 215.155.114.15>]
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 215.155.114.15>]
local  IP address 215.155.114.15
remote IP address 215.155.115.254
Script /etc/ppp/ip-up started (pid 3609)
Script /etc/ppp/ip-up finished (pid 3609), status = 0x0

It might be Microsoft VPN most likely, but I am not absolutely sure (how to 
check?).

local ~ ip route list
215.155.115.254 dev ppp0  proto kernel  scope link  src 215.155.114.15
192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.111
127.0.0.0/8 dev lo  scope link
default via 192.168.2.1 dev eth1

local ~ # ping -I ppp0 www.kernel.org
PING pub.us.kernel.org (204.152.191.5) from 215.155.114.15 ppp0: 56(84) bytes 
of data.

--- pub.us.kernel.org ping statistics ---
30 packets transmitted, 0 received, 100% packet loss, time 29008ms

ibm ~ # ping -I ppp0 215.155.115.254
PING 215.155.115.254 (215.155.115.254) from 215.155.114.15 ppp0: 56(84) bytes 
of data.
64 bytes from 215.155.115.254: icmp_seq=1 ttl=64 time=16.0 ms
64 bytes from 215.155.115.254: icmp_seq=2 ttl=64 time=12.5 ms
64 bytes from 215.155.115.254: icmp_seq=3 ttl=64 time=13.0 ms
64 bytes from 215.155.115.254: icmp_seq=4 ttl=64 time=15.4 ms
64 bytes from 215.155.115.254: icmp_seq=5 ttl=64 time=11.7 ms

--- 215.155.115.254 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 11.703/13.765/16.039/1.678 ms

local ~ # ifconfig
eth1      Link encap:Ethernet  HWaddr 01:0D:65:FA:82:F3
          inet addr:192.168.2.111  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6254696 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7275995 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:2655461882 (2532.4 Mb)  TX bytes:67477010 (64.3 Mb)
          Base address:0x8000 Memory:c0220000-c0240000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:444 errors:0 dropped:0 overruns:0 frame:0
          TX packets:444 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:52614 (51.3 Kb)  TX bytes:52614 (51.3 Kb)

ppp0      Link encap:Point-to-Point Protocol
          inet addr:215.155.114.15  P-t-P:215.155.115.254  
Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:996  Metric:1
          RX packets:40 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:3002 (2.9 Kb)  TX bytes:3008 (2.9 Kb)

local ~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
215.155.115.254 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth1

This should contain most of necessary information...

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Grant Taylor]

On 8/17/2008 6:20 AM, Jan Klod wrote:
> I think so, but how to check?

The output of ifconfig and the VPN client trace (local / remote IP 
lines) after the VPN is up tells us what we need to know.  Yes, the 
address you are pining is the other end of the VPN.  Good.

> local ~ # ip route list
> 192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.111
> 127.0.0.0/8 dev lo  scope link
> default via 192.168.2.1 dev eth1

*nod*

> pty pptp 193.13.128.6 --nolaunchpppd

Is 193.13.128.6 the IP of the VPN server you are establishing a VPN to? 
  (I'm going to presume yes for the rest of the discussion.)

> It might be Microsoft VPN most likely, but I am not absolutely sure (how to 
> check?).

It does not really matter.  It was more a point of interest that this is 
a PPTP VPN, not an SSL VPN, which is what OpenVPN provides.  Usually 
PPTP / L2TP VPNs are served up by a Microsoft VPN server where as IPSec 
/ SSL / other are served up by things that are not Microsoft. 
(PPTP/L2TP is built in to Routing and Remote Access from Microsoft.)

> local ~ ip route list
> 215.155.115.254 dev ppp0  proto kernel  scope link  src 215.155.114.15
> 192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.111
> 127.0.0.0/8 dev lo  scope link
> default via 192.168.2.1 dev eth1

*nod*  Here the VPN is up and we see a new network (the VPN) as I expect.

> local ~ # ifconfig
> eth1 ... inet addr:192.168.2.111  Bcast:192.168.2.255  Mask:255.255.255.0
> lo   ... inet addr:127.0.0.1  Mask:255.0.0.0
> ppp0 ... inet addr:215.155.114.15  P-t-P:215.155.115.254  Mask:255.255.255.255
> 
> local ~ # route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 215.155.115.254 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
> 192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
> 0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth1
> 
> This should contain most of necessary information...

Yes it does.  At this point I would think that you can issue the 
following commands (double check my syntax) and get the result you are 
wanting.

ip route add 193.13.128.6/32 via 192.168.2.1
ip route del default via 192.168.2.1
ip route add default via 215.155.115.254 metric 1
ip route add default via 192.168.2.1 metric 2

This should do the following:
  - Add an explicit route to get to the VPN server via your local router.
  - Delete your existing default gateway so we can (re)add the new one 
that you want.
  - Add a new default gateway that is the remote end of the VPN.
  - Add a new backup default gateway that is your local router so we 
still have a backup route to the net when your VPN is down.

At this point things should be functional for you.



Grant. . . .

active interface?

[Jan Klod]

I have an unanswered question: how active interface is determined in Linux? I 
mean, interface, which is used by web / mail / ping (default) ?

Re: active interface?

[Jan Engelhardt]

On Thursday 2008-08-21 09:32, Jan Klod wrote:

>I have an unanswered question: how active interface is determined in Linux? I 
>mean, interface, which is used by web / mail / ping (default) ?

Routing. You can obtain the kernel routing code's decision by

	ip route get $destination_address_here

There are a handful of parameters that influence the decision, such as 
TOS and fwmark.

Re: active interface?

[Grant Taylor]

On 08/21/08 08:32, Jan Klod wrote:
> I have an unanswered question: how active interface is determined in 
> Linux? I mean, interface, which is used by web / mail / ping 
> (default) ?

It's not an ""interface per say.  To the best of my knowledge what 
happens is that your routing stack chooses the best route (gateway) to 
send your request through.  Once it has the route selected it will use 
the interface facing said route as it's source IP unless a specific 
source IP has already been chosen by the application.



Grant. . . .

Re: VPN (interface) access for and all traffic through from single user -- how to do it?

[Jan Klod]

Well, I got it to work in a mode, where all traffic is going through VPN like 
this:

ip route add $IP_VPN_GATEWAY via $IP_LOCAL_GATEWAY dev eth1
ip route del $IP_REMOTE_VPN_ENDPOINT dev ppp0 src $IP_LOCAL_VPN_ENDPOINT
ip route del default via $IP_LOCAL_GATEWAY dev eth1 && ip route add default 
via $IP_VPN_GATEWAY dev ppp0

But is not as nice as I would like. 

I tried this to achieve my initial goal -- ppp0 for particular user:

	echo localIP_VPN = $1
        echo remoteIP_VPN = IP_VPN_GATEWAY = $2
        echo real interface = $3
        ip rule add from all fwmark 1 table net
        ip rule add from all fwmark 2 table net-2111
        ip route add table net default via $2 dev ppp0
        ip route add table net-2111 default via 0.0.0.0 dev $3
        ip route del $2 dev ppp0 src $1
        ip route flush cache

        iptables -t mangle -A OUTPUT -m mark --mark 1 -j ACCEPT
        iptables -t mangle -A PREROUTING -m mark --mark 2 -j ACCEPT
        iptables -t mangle -A OUTPUT -m mark ! --mark 1 -m owner --uid-owner 
articles -j MARK --set-mark 1
        iptables -t mangle -A PREROUTING -d $1 -m mark ! --mark 2 -j 
MARK --set-mark 2
        iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source $1

But that just didn't worked somehow. Please take a closer look at previous 
commands and give some advices about if that is what I should do...

As you see, I have two tables, so I hope to "take out" outgoing from user 
through ppp0 and forward replies back to eth1, which, I believe is listened 
to, when is default in route main table.

Jan