The source IP does not changing in the return flow, only the interface the packet returns on, in your case its returning on DMZ_1, not DMZ_2.
>From your logs you can see the IP is still 192.168.2.1. Deny TCP (no connection) from 192.168.2.1/23 to 10.10.10.140/9244 flags SYN ACK on interface DMZ_1 varaillon wrote: > Thank you for your replies! > > The problem is not so much the asymmetric of the traffic but more the change > of IP addresses source in the return flow: > > [IP_src:10.10.10.1,IP_dst:20.20.20.2]----TCP/SYN---->FWSM----->20.20.20.2 > > X--FWSM<---TCP/SYN/ACK----[IP_src: 20.20.20.1,IP_dst: 10.10.10.1] > > The ASA algorithm checks the validity of the return flow based on: > -Src IP > -Src Port > -Dest IP > -Dest Port > -Translation > > In my case the IP source/destination are not matching so the return flow is > dropped. > > To go back to the advised command: > > Given that I have only one FWSM, could this "asr-group" command work for me? > > Cisco says that this command: > "causes incoming packets to be re-classified with the interface of the same > asr-group if a flow with the incoming interface cannot be found." > > The above sounds good, but Cisco adds: > "If re-classification finds a flow with another interface, and the > associated context is in standby state, then the packet is forwarded to the > active unit for processing." > > In my case, since I have only one FWSM, the flow will never be associated > with a context in standby state, so I suspect that the re-classification > will not occur, and the packets will be dropped. > > Am I right? Or do I miss something here? > > Thanks > > Christophe > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Patrick McEvilly > Sent: Saturday, September 01, 2007 4:06 PM > To: [email protected] > Subject: [c-nsp] [Fwd: FWSM 3.1 and Servers with redundant cards] > > > > The FWSM supports asymmetric traffic using the asr-group configuration. > I believe this will do what you want it to do. > Patrick > >>From the docs. > > In some situations, return traffic for a session may be routed through a > different interface than it > originated from. In failover configurations, return traffic for a > connection that originated on one unit may > return through the peer unit. This most commonly occurs when two > interfaces on a single FWSM, or two > FWSMs in a failover pair, are connected to different service providers > and the outbound connection does > not use a NAT address. By default, the FWSM drops the return traffic > because there is no connection > information for the traffic. > You can prevent the return traffic from being dropped using the > asr-group command on interfaces where > this is likely to occur. When an interface configured with the asr-group > command receives a packet for > which it has no session information, it checks the session information > for the other interfaces that are in > the same group. > Note In failover configurations, you must enable Stateful Failover for > session information to be passed from > the standby unit or failover group to the active unit or failover group. > If it does not find a match, the packet is dropped. If it finds a match, > then one of the following actions > occurs: > . If the incoming traffic originated on a peer unit in a failover > configuration, some or all of the layer > 2 header is rewritten and the packet is redirected to the other unit. > This redirection continues as long > as the session is active. > . If the incoming traffic originated on a different interface on the > same unit, some or all of the layer > 2 header is rewritten and the packet is re-injected into the stream. > Note Using the asr-group command to configure asymmetric routing support > is more secure than using the > static command with the nailed option. > > Enter the following commands to add an interface to an asymmetric > routing group. Stateful Failover > must be enabled for asymmetric routing support to function properly > between units in failover > configurations. > hostname/ctx1(config)# interface if > hostname/ctx1(config-if)# asr-group num > Valid values for num range from 1 to 32. You need to enter the command > for each interface that will > participate in the ASR group. You can view the number of ASR packets > transmitted, received, or dropped > by an interface using the show interface detail command. > You can create up to 32 ASR groups and assign a maximum of 8 interfaces > to each group. > Note The upstream and downstream routers must use one MAC address per > VLAN and have different MAC > addresses for different VLANs to allow for the redirection of packets > from a standby unit to an active > unit in failover configurations. > > > > Hi, > > > For redundancy reasons, we have a server with two network cards. > > Each card belongs to a subnet and each subnet to a different DMZ. > > The server has two default routes with different metrics, where the prefered > default route is in the DMZ_1. > > > +--------+-card_1--192.168.1.1/24----DMZ_1--+--------+ > | SERVER | | FWSM |---OUTSIDE > +--------+-card_2--192.168.2.1/24----DMZ_2--+--------+ > > > The problem is that when we telnet from the outside to the ip destination > 192.168.2.1, the server replies using the ip source 192.168.1.1. > > So the FWSM blocs, as it should, the SYN/ACK from the server: > > %FWSM-6-302013: > Built inbound TCP connection 146242008855220280 > for OUTSIDE:10.10.10.140/9244 (10.10.10.140/9244) > to DMZ_2:192.168.2.1/23 (192.168.2.1/23) > > %FWSM-6-106015: > Deny TCP (no connection) > from 192.168.2.1/23 to 10.10.10.140/9244 > flags SYN ACK on interface DMZ_1 > > Given that we have one FWSM (so no exchange of states), is there anyway to > overcome that issue from the FWSM? > > Would it help to bring each DMZ in its own context? > > Any comment will be welcomed. > > Thank you. > > > Christophe > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > __________ NOD32 2498 (20070902) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
