Screen OS

Hi,

I've got a nat-related problem with a ssg5 (tested that on serveral ssg5 at different ISPs with the same issue.).

I dont have that problem with other devices (thomson, cisco, dlink, linksys, some more).

Those servers are: 194.124.229.58 + 194.124.229.59 port 6665-6669, which is irc.de.quakenet.org

The basic setup for testing purposes:
- eth0/0 outgoing with pppoe
- bgroup0 LAN with NAT enabled (no change btw with policy NAT instead of interface)
- policy allowing local to any remote

I can telnet 194.124.229.58 port 6667 at the ssg
I can NOT telnet 194.124.229.58 port 6667 from behind the LAN
I can telnet any other irc server I tested so far

When I turn on logging at a specific irc related policy, I can see the matching outgoing bytes, but none incoming.
For other IPs then the both mentioned above, I receive data.
I also dont have any other NAT related issues.

I tried disabling all security related features, no change
I tried policy nat instead of interface nat. No change.
The debug flow basic shows me no data received when initiating a connection from bgroup0:

post addr xlation: x.x.x.x->194.124.229.59. u
pdate policy out counter info.
send out through normal path.
flow_ip_send: 26af:x.x.x.x->194.124.229.59,6 => ethernet0/0(48) flag 0x0, vlan 0
send packet to traffic shaping queue.


But nothing comes back. (btw. there is no traffic shaping enabled anywhere)

If i tried the same locally at the ssg, with telnet 194.124.229.59 port 6667
get db str shows me something else:

Send to ethernet0/0 (62) ****** 25375.0:  
packet received [83]****** ipid = 38689(9721), @03876478
packet passed sanity check.
flow_decap_vector IPv4 process ethernet0/0:194.124.229.59/6667->x.x.x.x/39627,6
existing session found.
sess token 4 flow got session. flow session id 8019 flow_main_body_vector in ifp ethernet0/0 out ifp N/A
flow vector index 0x202, vector addr 0x9969724, orig vector 0x9969724
post addr xlation: 194.124.229.59->x.x.x.x.

So basically the server is reachable but not from behind nat. Why is this and what can I do solve that issue? I was wondering if the target server does block low source ports (the ssg uses 1500-2500 for translation)

Regards

In the meantime I tunnel the irc traffic with vpn through a secondary LANCOM Firewall, which does not have that issue.
I also tried different mss/mtu values/Settings, but that does not seem to be the issue here. Its just like the target server dislikes the juniper devices.

FYI, this is the full debug log (changed external IP and internal MAC )

 

juniper-> get db str
****** 713371.0: <Trust/bgroup0> packet received [52]******
ipid = 7233(1c41), @03964170
packet passed sanity check.
flow_decap_vector IPv4 process
bgroup0:192.168.23.77/62184->194.124.229.59/6667,6<Root>
no session found
flow_first_sanity_check: in <bgroup0>, out <N/A>
searching for session cache
Cache session not found
chose interface bgroup0 as incoming nat if.
flow_first_routing: in <bgroup0>, out <N/A>
search route to (bgroup0, 192.168.23.77->194.124.229.59) in vr trust-vr for vs d-0/flag-0/ifp-null
cached route 0 for 194.124.229.59
add route 45 for 194.124.229.59 to route cache table
[ Dest] 45.route 194.124.229.59->213.191.89.3, to ethernet0/0
routed (x_dst_ip 194.124.229.59) from bgroup0 (bgroup0 in 0) to ethernet0/0
policy search from zone 2-> zone 1
policy_flow_search policy search nat_crt from zone 2-> zone 1
RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 194. 124.229.59, port 6667, proto 6)
No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 21/0/0x1
Permitted by policy 21
dip id = 2, 192.168.23.77/62184->4.3.2.1/1755
choose interface ethernet0/0 as outgoing phy if
no loop on ifp ethernet0/0.
session application type 32, name None, nas_id 0, timeout 131070sec
ALG vector is not attached
service lookup identified service 0.
flow_first_final_check: in <bgroup0>, out <ethernet0/0>
existing vector list 3-51c1e1c.
Session (id:7856) created for first pak 3
flow_first_install_session======>
route to 213.191.89.3
bypass L2 prepare if, nsp ready.
ifp2 ethernet0/0, out_ifp ethernet0/0, flag 10002800, tunnel ffffffff, rc 1
outgoing wing prepared, ready
handle cleartext reverse route
search route to (ethernet0/0, 194.124.229.59->192.168.23.77) in vr trust-vr fo r vsd-0/flag-3000/ifp-bgroup0
cached route 3 for 192.168.23.77
[ Dest] 3.route 192.168.23.77->192.168.23.77, to bgroup0
route to 192.168.23.77
cached arp entry with MAC 000129FFFFFF for 192.168.23.77
arp entry found for 192.168.23.77
ifp2 bgroup0, out_ifp bgroup0, flag 00800801, tunnel ffffffff, rc 1
created session cache entry (192.168.23.77->194.124.229.59/6667) with index 1 54 way 0
flow got session.
flow session id 7856
flow_main_body_vector in ifp bgroup0 out ifp ethernet0/0
flow vector index 0x3, vector addr 0x1ff2a30, orig vector 0x1ff2a30
adjust tcp mss.
Got syn, 192.168.23.77(62184)->194.124.229.59(6667), nspflag 0x801801, 0x10002 800
post addr xlation: 4.3.2.1->194.124.229.59.
send out through normal path.
flow_ip_send: 1c41:4.3.2.1->194.124.229.59,6 => ethernet0/0(52) flag 0x0, vlan 0
send packet to traffic shaping queue.
flow_ip_send: 1c41:4.3.2.1->194.124.229.59,6 => ethernet0/0(52) flag 0x20 000, vlan 0
pak has mac
Send to ethernet0/0 (74)
****** 713374.0: <Trust/bgroup0> packet received [52]******
ipid = 7266(1c62), @0396f170
packet passed sanity check.
flow_decap_vector IPv4 process
bgroup0:192.168.23.77/62184->194.124.229.59/6667,6<Root>
existing session found. sess token 3
flow got session.
flow session id 7856
flow_main_body_vector in ifp bgroup0 out ifp N/A
flow vector index 0x3, vector addr 0x1ff2a30, orig vector 0x1ff2a30
adjust tcp mss.
Got syn, 192.168.23.77(62184)->194.124.229.59(6667), nspflag 0x801801, 0x10002 800
post addr xlation: 4.3.2.1->194.124.229.59.
send out through normal path.
flow_ip_send: 1c62:4.3.2.1->194.124.229.59,6 => ethernet0/0(52) flag 0x0, vlan 0
send packet to traffic shaping queue.

FINE

Hi,

 

If I understand you correctly, you are trying to establish a looping connection from the trusted LAN to to the trusted servers using public addresses on the untrust interface. Are these addresses MIPs/VIPs or policy- beased NATs? Are outgoing connection correctly source-NATted to a public IP belonging to the untrust interface network?

 

Kind regards,

Edouard

Hi,

 

no this is a trust --> untrust connection.

eth0/0 = pppoe internet

 

LAN <-NAT-> Internet.

 

As I mentioned in the first starting message of this topic:

bgroup (LAN) is i NAT mode, policy is just permit.

Every other NAT connection is fine.

I can reach from bgroup0 with nat some other irc servers

I can reach the specific servers directy from the firewall with telnet

I can NOT reach the specific servers from bgroup0 with nat.

 

I dont have any other NAT issues.

 

The logs tells me, the traffic is source-translated (with eth0/0 ip) to destination, then sent to traffic shaping queue. Where it disappears.

Hi!

 

Yes, I see now. This seems to be a fragmentation/MSS issue.  Try to reduce the MTU size on the bgroup0 interface to 1300 to avoid the packet fragmentation while the packets are crossing the firewall. A would also recommend to read the KB articles 4586, 14290, 6346 and other ones, that conatin the words "MSS"; "MTU", "fragmentation"

 

Kind regards,

Edouard

Hi, just wanted to let you know that this problem still exists. Even with the latest 6.3r9 firmware. To the moment I have 5 SSG firewalls and all of them (!) behave the same. All have DSL PPPOE connections. I tried all MSS / MTU related Solutions, nothing works. I dont believe that this wouldw be the issue, as packets below 1480 bytes wont be fragmented at all. So far I "solved" this by tunneling the traffic via ipsec though lancom router at remote sites. So at least I can connect. But this is not perfect, as it adds extra latency. I would be interested, if this could be resolved with JunOS SRX walls.

hi schnee

 

understand you are not enable any traffic shapping, but something weird why on your debug log mention that the traffic in traffic shapping queue. to isolate the issue, 

1. try to disable traffic shapping globally

        => set traffic-shaping mode off

2. have you tried to used dip rather than interface base nat?

 

 

thanks

 

EL

Hi Elkim, as I understand, traffic is always routed to traffic shaping queue, no matter if enabled or not. If enabled, traffic is shaped then, if not, nothing else happens. At least the log looks always the same (I questioned myself the same some time ago when I saw this). I only have 1 IP, so DIP would not be the answer, together with needed vip. But I see, that I would have different source-port translation options. My guess is, that the source-nat is using ports below 1024, allthough clients usually use higher ports. And those source ports are blocked by destination. I cant see any traffic coming back. But I also dont have this issue with any other firewall/nat-device. Can you e.g. test it by yourself? telnet to 194.124.229.59 port 6667 with a screenos device behind nat?

Hi Schnee

 

btw how you configure interface base nat? do u only enable nat mode on brgroup0 and the just enable policy or you set interface bgroup0 to route mode and the you create policy based nat with dip using egress interface

 

 

thanks

 

EL

Hi Schnee,

 

Try to select "Application" "Telnet" in the policy.

@elkim

bgroup0 is set to nat mode. Also tried with policy, does not change anything.

 

@echidov

Interesting idea. But no change 😞

I tried now almost every ALG, no change.

This is what the policy log looks like:

(the last hit was any other irc server).

The mystery is: from the firewall itself I can telnet the irc server 194.124.229.59 at port 6667. So something must be wrong with the nat applying.

 

2011-10-03 09:52:44 10.11.204.200:11389 66.225.225.66:6667 12.213.32.68:1194 66.225.225.66:6667 IRC 20 sec. 770 749 Close - TCP FIN

2011-10-03 09:51:58 10.11.204.200:11360 194.124.229.59:6667 12.123.32.68:2772 194.124.229.59:6667 IRC 22 sec. 198 0 Close - AGE OUT

2011-10-03 09:50:56 10.11.204.200:11330 194.124.229.59:6667 12.213.32.68:1813 194.124.229.59:6667 IRC 21 sec. 198 0 Close - AGE OUT

2011-10-03 09:49:58 10.11.204.200:11295 194.124.229.59:6667 12.213.32.68:2430 194.124.229.59:6667 IRC 21 sec. 198 0 Close - AGE OUT

2011-10-03 09:47:25 10.11.204.200:11242 194.124.229.59:6667 12.213.32.68:2300 194.124.229.59:6667 IRC 18 sec. 198 0 Close - AGE OUT

2011-10-03 09:46:45 10.11.204.200:11223 194.124.229.59:6667 12.213.32.68:1074 194.124.229.59:6667 IRC 22 sec. 198 0 Close - AGE OUT

2011-10-03 09:44:25 10.11.204.200:11162 194.124.229.59:6667 12.213.32.68:2955 194.124.229.59:6667 IRC 20 sec. 198 0 Close - AGE OUT

2011-10-03 09:43:23 10.11.204.200:11129 194.124.229.59:6667 12.213.32.68:2670 194.124.229.59:6667 IRC 22 sec. 198 0 Close - AGE OUT

2011-10-03 09:40:15 10.11.204.200:12081 194.124.229.59:6667 12.213.32.68:1272 194.124.229.59:6667 IRC 21 sec. 198 0 Close - AGE OUT

2011-10-03 09:39:29 10.11.204.200:12052 194.124.229.59:6667 12.213.32.68:2756 194.124.229.59:6667 IRC 22 sec. 198 0 Close - AGE OUT

2011-10-03 09:37:49 10.11.204.200:11972 194.124.229.59:6667 12.213.32.68:2719 194.124.229.59:6667 IRC 23 sec. 198 0 Close - AGE OUT

 

I believe that the source ports (below 10.000) are the problem. When e.g. testing behind other bsd based walls, I have NAT Sessions above 50.000:

 

172.20.1.105:55974 -> 12.123.2.254:48160 -> 194.124.229.59:6667

 

This is just an random example, this problem did never occur with any other nat device.

 

If this was the issue, is there any way to "force" the NAT to use higher ports?

An extreme way could be to reserve all ports up to 10.000 with I VIP.

|edit| I tried this now, wanted to add a custom service with destination Ports 1024-12.000. This did not work, error: "insufficient virtual ports in pool [...] 57 available. so this is not an option.

Hi,

 

Most likely the firewall on the remote site is configured so that any IRC-connections with the lower port numbers are dropped. But ScreenOS starts with quite low numbers while performing PAT. I do not know if it possible to force ScreenOS to use the higher port numbers. I have found another workaround and configured a DIP with the "Fixed-port" option. This worked for me. But if you have many IRC users it is possible that two or more of them may try to establish connections from the same src-port. This should not be a big problem. A second attempt should use another port number after the first one has failed. Or you can assign smaller and different port ranges to the IRC clients, if it's possible.

OK. That sounds promising.

 

I never used that beforce, as I understood dip, it assigns different source IP Adresse if you have a lager subnet on the external interface.

 

I have only 1 IP on external interface (eth0/1) /32.

Can you hint me where and how to configure the dip for this?

On the lan-bgroup0?

Hi,

 

That's correct. DIP is used for the policy based src-NAT.  The src-NAT to the egress interface is namely also a DIP, but predifined one. Unfortunately you cannot change the way how it works 😞  Both interface based NAT and policy based NAT to the interface IP use the port numbers from 1024 to 65535. To configure a "fixed-port DIP" you need at least one more public IP routed towards the FW. Can you purchase one more IP or a small network at your ISP? This IP(s) can be configured as DIP(s) on the untrust interface.

Thank you for the explanation.

 

So there is no solution for my problem, as long there is no way found to change the default DIP behaviour.

There are other ISP, which support more addresses or bigger subnets. But for these standard PPPOE connections, I am limited to one /32 static address. For DSL uplinks in germany there are not too much options.

 

So I keep routing the traffic to these specific addresses through vpn.

 

Do you know if this behaviour is the same with the Junos SRX series? That could be a possible replacement.

 

 

Hi,

 

Tut mir Leid, I do not know if SRX does PAT in a different manner or can be forced to use the higher port numbers. Try to post your question to the SRX forum.