Update:
I've tried a variation of the fake static-ARP entry (see
http://blogs.sun.com/ford/entry/using_nat_in_the_global ) by attaching the
local zone to the ISP uplink (e1000g1), and giving it a private address from a
different subnet (192.168.151.80).
I defined 192.168.151.1 as another default router, made a static ARP entry with
the ISP's router address, and defined two basic IPFilter setups:
# cat ipf.conf
pass in quick all
pass out quick all
# cat ipnat.conf
rdr e1000g1 0/0 port 80 -> 192.168.151.80 port 22 tcp
map e1000g1 192.168.0.0/16 -> xxx.xxx.xxx.xxx/32
(X marks the ISP-provided IP address; I published the SSH server on port 80 for
tests - it does work locally within the T2000 box)
Tracing the route works, but neither TCP in nor TCP out - they don't.
According to snoop, when I try to "telnet www.ru 80" from the global zone (and
the connection works), and when I do it from the local zone (and the connection
doesn't work) packets seem the same:
[EMAIL PROTECTED] /etc/ipf]# snoop -r -d e1000g1 tcp port 80
Using device /dev/e1000g1 (promiscuous mode)
# From global
xxx.xxx.xxx.xxx -> 194.87.0.50 HTTP C port=32818
194.87.0.50 -> xxx.xxx.xxx.xxx HTTP R port=32818
xxx.xxx.xxx.xxx -> 194.87.0.50 HTTP C port=32818
xxx.xxx.xxx.xxx -> 194.87.0.50 HTTP (body)
194.87.0.50 -> xxx.xxx.xxx.xxx HTTP R port=32818
194.87.0.50 -> xxx.xxx.xxx.xxx HTTP HTTP/1.0 400 Bad Request
xxx.xxx.xxx.xxx -> 194.87.0.50 HTTP C port=32818
194.87.0.50 -> xxx.xxx.xxx.xxx HTTP Cache-Control: no-cache
xxx.xxx.xxx.xxx -> 194.87.0.50 HTTP C port=32818
xxx.xxx.xxx.xxx -> 194.87.0.50 HTTP C port=32818
194.87.0.50 -> xxx.xxx.xxx.xxx HTTP R port=32818
# from local
xxx.xxx.xxx.xxx -> 194.87.0.50 HTTP C port=32819
xxx.xxx.xxx.xxx -> 194.87.0.50 HTTP C port=32819
...
Here's the stats - a nat session seems to exist...
[EMAIL PROTECTED] /etc/ipf]# ipfstat -hoi; ipnat -l
503 pass out quick all
481 pass in quick all
List of active MAP/Redirect filters:
rdr e1000g1 0.0.0.0/0 port 80 -> 192.168.151.80 port 22 tcp
map e1000g1 192.168.0.0/16 -> xxx.xxx.xxx.xxx/32
List of active sessions:
MAP 192.168.151.80 32819 <- -> xxx.xxx.xxx.xxx 32819 [194.87.0.50 80]
---
Likewise, if I try to access the published TCP service from my IP
yyy.yyy.yyy.yyy, the response-packets don't pass very far:
# snoop -r -d e1000g1 tcp port 80
Using device /dev/e1000g1 (promiscuous mode)
yyy.yyy.yyy.yyy -> xxx.xxx.xxx.xxx HTTP C port=4759
xxx.xxx.xxx.xxx -> yyy.yyy.yyy.yyy HTTP R port=4759
yyy.yyy.yyy.yyy -> xxx.xxx.xxx.xxx HTTP C port=4759
xxx.xxx.xxx.xxx -> yyy.yyy.yyy.yyy HTTP R port=4759
xxx.xxx.xxx.xxx -> yyy.yyy.yyy.yyy HTTP R port=4759
yyy.yyy.yyy.yyy -> xxx.xxx.xxx.xxx HTTP C port=4759
xxx.xxx.xxx.xxx -> yyy.yyy.yyy.yyy HTTP R port=4759
xxx.xxx.xxx.xxx -> yyy.yyy.yyy.yyy HTTP R port=4759
---
Traceroute from the local zone works, however, just like from the global zone:
[EMAIL PROTECTED] /]# traceroute -nI 194.87.0.50
traceroute to 194.87.0.50 (194.87.0.50), 30 hops max, 40 byte packets
1 xxx.xxx.xxx.gwy 0.965 ms 0.807 ms 0.797 ms
2 212.23.64.129 0.736 ms 0.647 ms 0.655 ms
3 87.226.232.249 1.173 ms 1.211 ms 1.219 ms
4 87.226.133.42 29.428 ms 29.186 ms 29.332 ms
5 193.232.244.187 29.425 ms 45.632 ms 29.614 ms
6 87.245.253.10 29.852 ms 30.023 ms 30.173 ms
7 194.87.0.83 31.393 ms 30.590 ms 31.163 ms
8 194.87.0.50 32.644 ms 30.872 ms 34.538 ms
[EMAIL PROTECTED] /etc/ipf]# traceroute -nI 194.87.0.50
traceroute: Warning: Multiple interfaces found; using xxx.xxx.xxx.xxx @ e1000g1
traceroute to 194.87.0.50 (194.87.0.50), 30 hops max, 40 byte packets
1 xxx.xxx.xxx.gwy 0.865 ms 0.806 ms 1.070 ms
2 212.23.64.129 0.723 ms 0.640 ms 0.650 ms
3 87.226.232.249 1.163 ms 1.201 ms 1.216 ms
4 87.226.133.42 29.146 ms 34.946 ms 29.190 ms
5 193.232.244.187 29.417 ms 29.603 ms 29.476 ms
6 87.245.253.10 29.841 ms 29.599 ms 29.610 ms
7 194.87.0.83 30.542 ms 30.591 ms 30.875 ms
8 194.87.0.50 30.814 ms 31.711 ms 31.440 ms
---
One more thing to note: at the moment the system is Solaris 10 u4 with
Recommended patches from Jan 21, 2008; however the IP Filter package is
replaced by the open-source 4.1.29 version (I faced the stock 4.1.9 version's
bugs with Linux TCP window scaling in another project, so by default I replace
it with the latest open-source release).
Will try to put the Sun release back, now...
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
[email protected]