Home » Mailing list archives » freebsd-pf » 2011 » January » 4

Re: transparent proxy

Previous thread: Current problem reports assigned to freebsd-pf@FreeBSD.org by FreeBSD bugmaster on Monday, December 27, 2010 - 4:07 am. (1 message)

Next thread: Current problem reports assigned to freebsd-pf@FreeBSD.org by FreeBSD bugmaster on Monday, January 3, 2011 - 4:07 am. (1 message)
[view original message]
From: jay
Subject: transparent proxy
Date: Saturday, January 1, 2011 - 9:38 pm

Folks,

I am trying to use stunnel & pf to devise a transparent proxy, but am
unable to figure out how to do it.  What I have is ext ip -> stunnel ->
http service, but the http service does not know where to route back the
packets, and remains in a sync state.


00:40:28.313038 IP 192.168.103.2.51791 > 127.0.0.1.80: Flags [S], seq
2806128000, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val
2027735 ecr 0], length 0
00:40:31.306553 IP 192.168.103.2.51791 > 127.0.0.1.80: Flags [S], seq
2806128000, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val
2028035 ecr 0], length 0
00:40:34.506518 IP 192.168.103.2.51791 > 127.0.0.1.80: Flags [S], seq
2806128000, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val
2028355 ecr 0], length 0
00:40:37.706528 IP 192.168.103.2.51791 > 127.0.0.1.80: Flags [S], seq
2806128000, win 65535, options [mss 16344,sackOK,eol], length 0

rpminit# netstat -ln
Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address       (state)
tcp4       0      0 192.168.103.2.51218    127.0.0.1.80           SYN_SENT
tcp4       0      0 192.168.103.62.443    192.168.103.2.51218    ESTABLISHED


If I disable the transparent config setting the communication is works,
but http access logs show the request coming from local host.

00:26:53.435415 IP 127.0.0.1.30655 > 127.0.0.1.80: Flags [P.], ack 1, win
8960, options [nop,nop,TS val 1946248 ecr 3625203070], length 6
00:26:53.435864 IP 127.0.0.1.80 > 127.0.0.1.30655: Flags [P.], ack 7, win
8960, options [nop,nop,TS val 3625203735 ecr 1946248], length 44
00:26:53.436426 IP 127.0.0.1.80 > 127.0.0.1.30655: Flags [F.], seq 45, ack
7, win 8960, options [nop,nop,TS val 3625203735 ecr 1946248], length 0
00:26:53.436463 IP 127.0.0.1.30655 > 127.0.0.1.80: Flags [.], ack 46, win
8960, options [nop,nop,TS val 1946248 ecr 3625203735], length 0
00:26:53.526062 IP 127.0.0.1.30655 > 127.0.0.1.80: Flags [F.], seq 7, ack
46, win 8960, options [nop,nop,TS val 1946257 ecr 3625203735], ...
[ message continues ]
[view original message]
From: Damien Fleuriot
Subject: Re: transparent proxy
Date: Sunday, January 2, 2011 - 7:25 am

Hi Jay,



I'm not sure what you're trying to achieve here.

Are you actually using proxy software at all, or only a PF redirect rule ?

Are you trying to set up a FORWARD or a REVERSE proxy ?

What do you use stunnel for, SSL/TLS connectivity ?


_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[ message continues ]
[view original message]
From: jay
Subject: Re: transparent proxy
Date: Sunday, January 2, 2011 - 10:37 am

Hi Damien,

Here I am using HTTP traffic as an illustration, but for other generic
services without the built in SSL layer, it would be highly advantageous
to be able to add stunnel to do the job. The target application (e.g. VNC,
database client/server connection, and so on) need not be re-coded.
Running stunnel as an intermediate layer has the side effect of connecting
to the internal services from a local IP address. In this configuration,
it becomes a proxy service that takes the incoming network communication,
filters out the SSL traffic and passes along the service payload as well
as back again. Stunnel is being used for SSL/TLS connectivity. The
"transparent" setting, available on Linux platforms, would bind() to a
foreign address prior calling connect(), issue an IP_TPROXY_ASSIGN
setsockopt to register the local address as a proxy, and use iptables and
ip routing rules to keep track of the forward and reverse routing. To the
service on the other side, it appears the client network traffic
originates from a foreign IP address. We patched stunnel for v.8.1 of
FreeBSD to use setsockopt IP_BINDANY, and thus preserve the foreign
address, but for the service on the other side, it tries to establish the
connection and fails because the routing is not set up to return the
traffic to stunnel. Without transparent mode, network communication is :

ext ip -> stunnel -> int ip -> http service

For int ip -> http svc, real tcpdump traffic is  :

00:26:53.435415 IP 127.0.0.1.30655 > 127.0.0.1.80: Flags [P.], ack 1, ...

On the other side, e.g. the return path:

http -> int ip -> stunnel -> ext ip

At the http svc, packets are sent as :

00:26:53.435864 IP 127.0.0.1.80 > 127.0.0.1.30655: Flags [P.], ack 7, ...

This works perfectly, but according the apache logs, the request looks
like they are all originate from the internal '127.0.0.1' address. Now
with transparent mode, it is :

ext ip -> stunnel -> ext ip -> http

00:40:28.313038 IP 192.168.103.2.51791 > 127.0.0.1.80: ...
[ message continues ]
[view original message]
From: Damien Fleuriot
Subject: Re: transparent proxy
Date: Sunday, January 2, 2011 - 10:50 am

In other software such as HTTP that you took for example, there's this
special X-Forwarded-For header which covers this very need.

IMO you shouldn't have to tweak around with the firewall or the IP stack
to make up for a missing capability but nvm.


Perhaps these 2 PF rules would be of use to you:

     route-to
           The route-to option routes the packet to the specified interface
           with an optional address for the next hop.  When a route-to rule
           creates state, only packets that pass in the same direction
as the
           filter rule specifies will be routed in this way.  Packets
passing
           in the opposite direction (replies) are not affected and are
routed
           normally.

     reply-to
           The reply-to option is similar to route-to, but routes
packets that
           pass in the opposite direction (replies) to the specified inter-
           face.  Opposite direction is only defined in the context of a
state
           entry, and reply-to is useful only in rules that create
state.  It
           can be used on systems with multiple external connections to
route
           all outgoing packets of a connection through the interface the
           incoming connection arrived through (symmetric routing enforce-
           ment).



_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[ message continues ]
[view original message]
From: jay
Subject: Re: transparent proxy
Date: Sunday, January 2, 2011 - 1:04 pm

Squid can talk SSL, so insertion of XFF is possible. But for other

I don't think I need to make up for a missing capability, as man 4 ip says :

If the IP_BINDANY option is enabled on a SOCK_STREAM, SOCK_DGRAM or a
     SOCK_RAW socket, one can bind(2) to any address, even one not bound to
     any available network interface in the system.  This functionality (in
     conjunction with special firewall rules) can be used for implementing a
     transparent proxy.  The PRIV_NETINET_BINDANY privilege is needed to set
     this option.

http://www.freebsd.org/cgi/man.cgi?query=ip&apropos=0&sektion=0&manpath=Fr...


Here I want :

nn:nn:nn.nnnnnn IP 127.0.0.1.51791 > 192.168.103.2.80: Flags [S], ack ...

int_if="lo0"
ext_if="ed0"

pass in on $int_if route-to ($int_if 127.0.0.1) from 192.168.103.1 keep state

But no good (it's not able to sync) :


20:02:17.282414 IP 192.168.103.2.56991 > 127.0.0.1.80: Flags [S], seq
3005214022, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val
8998630 ecr 0], length 0
20:02:20.276987 IP 192.168.103.2.56991 > 127.0.0.1.80: Flags [S], seq
3005214022, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val
8998930 ecr 0], length 0
20:02:23.477037 IP 192.168.103.2.56991 > 127.0.0.1.80: Flags [S], seq
3005214022, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val
8999250 ecr 0], length 0
20:02:26.677036 IP 192.168.103.2.56991 > 127.0.0.1.80: Flags [S], seq
3005214022, win 65535, options [mss 16344,sackOK,eol], length 0

Visualizing the result of the rule is not too keen.

Thanks

_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[ message continues ]
[view original message]
From: Damien Fleuriot
Subject: Re: transparent proxy
Date: Sunday, January 2, 2011 - 1:16 pm

How do things go when using synproxy in your pass rule ?

Something like: pass in log on $int_if route-to ($int_if 127.0.0.1) from
192.168.103.1 synproxy state
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[ message continues ]
[view original message]
From: jay
Subject: Re: transparent proxy
Date: Sunday, January 2, 2011 - 2:57 pm

Is there a way to see what the rule is doing? It didn't have any effect.
I've been trying different combinations, sometimes targeting


_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[ message continues ]
[view original message]
From: jay
Subject: Re: transparent proxy
Date: Sunday, January 2, 2011 - 2:59 pm

>From studying squid rules, I found the following pf rule set. Does this do
something similar to what I'm after? I tried something like this but it
didn't help.

int_if="gem0"
ext_if="kue0"

rdr on $int_if inet proto tcp from any to any port www -> 127.0.0.1 port 3128

pass in on $int_if inet proto tcp from any to 127.0.0.1 port 3128 keep state
pass out on $ext_if inet proto tcp from any to any port www keep state

http://www.benzedrine.cx/transquid.html



_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[ message continues ]
[view original message]
From: Damien Fleuriot
Subject: Re: transparent proxy
Date: Sunday, January 2, 2011 - 3:07 pm

Allow me to explain the rules in detail.

1/ redirect all traffic that passes through us from anyone to anywhere
on port 80 to the local machine on port 3128

2/ Actually allow everyone to contact the local machine on port 3128
(this has the same effect as if you had written "rdr pass" in the first
rule)

3/ Allow outgoing traffic on our external interface to web servers
(which comes in use if you don't have a "pass out" rule for everything)


However regarding squid you need to compile it with the transparent
proxy for PF option, so there's likely special code to be enabled in squid.

_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[ message continues ]
[view original message]
From: jay
Subject: Re: transparent proxy
Date: Monday, January 3, 2011 - 6:56 pm

Interesting, the client shows :

CONNECTED(00000003)

Pflog shows  (this time 192.168.103.69 was used in place of 192.168.103.1):

1294126958.718778 rule 0/0(match): pass in on ed0: (tos 0x0, ttl 64, id
6708, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.103.69.51472 > 192.168.103.62.443: Flags [S], cksum 0xb80b
(correct), seq 4218566242, win 5840, options [mss 1460,sackOK,TS val
5844054 ecr 0,nop,wscale 7], length 0

For tcpdump, there was no network communication. I guess it's close, but
not yet working.

_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

[ message continues ]
Previous thread: Current problem reports assigned to freebsd-pf@FreeBSD.org by FreeBSD bugmaster on Monday, December 27, 2010 - 4:07 am. (1 message)

Next thread: Current problem reports assigned to freebsd-pf@FreeBSD.org by FreeBSD bugmaster on Monday, January 3, 2011 - 4:07 am. (1 message)