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]

Reply via email to